Re:Have they decided to implement security yet?
on
OpenBSD 4.8 Released
·
· Score: 1
Wow kid, you've got issues.
*PLONK*
Re:Have they decided to implement security yet?
on
OpenBSD 4.8 Released
·
· Score: 1
HI. No, that isn't what I am arguing. I am not arguing MAC vs integrated cryptography, I am saying the OpenBSD team is falling behind by continually rejecting MAC in all it's forms and need to catch up if they still want to be known as a secure operating system.
See, you are a troll. Your argument in the OBSD post was simple zealotism without understanding what you are saying, as evidenced by your lack of a reply. Then you couldn't let go and troll with the same shit in a completely different thread. Funny:)
I understand you don't have a great understanding of security practicies, so let me enlighten you. MAC is great as an additional layer of protection and enforce least privilege. That doesn't mean we should ignore security vulnerabilities. Got it? Great.
Is that Android now dominates the Smartphone market. Thank fuck. The less dominance Apple have with their fucked up control everything for you polices only a good thing.
I don't know much about these platforms, but Android is based on Linux yes? SO would many of these vulns still be in Linux?
I'm not confusing anything. This paper shows Chrome still lacks full ALSR support, although I admit I thought it was more than just that one DLL. Nice to know about the proper protected mode stuff though.
For all the flak IE gets, it's actually a great browser. We all know Microsoft make great products and often take the lead when forced to, and now is no different.
It is also the most secure browser by far, what with its inherent use of MAC, and full DEP and ALSR support. Strange, but true.
Re:Have they decided to implement security yet?
on
OpenBSD 4.8 Released
·
· Score: 1
For varying definitions of compromised, you mean? If the Sysadmin has deployed a detailed MAC policy.
Nope, not at all. Regardless of if you use AppArmor, RSBAC, SELinux, Tomoko, SMACK or GRSecurity, it is trivial to deny write access to files from a user who owns them. It doesn't have to be a detailed MAC policy, and the only time that won't hold true is if there is a remote kernel exploit. Which...is pretty rare.
This is a good argument, but it's really hard to just say "Far less likely with MAC". This is always going to be the System Administrators responsibility. In fact all aspects of system security are going to be delegated to the system's managers almost immediately. This is the point where YOU need to decide if OpenBSD will suit your needs or become to complex to manage for your particular task.
I think you are getting away from my point by saying that all security is ultimately the administrators responsibility. I agree, and OpenBSD only provides basic unix permissions to enforce this. I am aware of the other stuff such as ALSR, but it doesn't come close to MAC. It's all based on stopping exploits, and there is very little in the way of dealing with a successful exploit.
This is goofy, I'm not sure I can think of a *nix system that doesn't allow you to disable root. On the other hand, I believe this is correct, with the exception that I don't believe there are any legal governance bodies in operation currently defining a proper MAC policy and implementation. Meaning that you could never prove OpenBSD was actually capable of meeting them or not, neither can you prove that SELinux meets these requirements. We only know that it did not happen while that government body was in place.
Any Linux system has multiple MAC implementations in the kernel, so they allow this. As does FreeBSD via TrustedBSD. It is an import step in implementing proper separation of duty.
Setuid, of course systrace will run right over setuid, but anyone who can set policy on a MAC system is a point of privilege elevation as well.
Setuid is not at all the same thing, and is arguably worse as that process then inherits the full complete rights as the user it is running as. If I want to launch a process as administrator because it needs to bind to a low port, that does not mean I want it to have write access to/etc.
Additionally, it is not true that anyone who can set policy on a MAC system is at a point of privilege elevation. Generally the user account to administer a MAC system is a standard unix account, which must be hacked in addition to the root account. The root account can do nothing to the MAC permissions and the normal user can do nothing useful except with its own files.
Re:Have they decided to implement security yet?
on
OpenBSD 4.8 Released
·
· Score: 4, Interesting
I can't believe you got modded up. MAC is not bolted on at all, it is a kernel patch. This means you end up with a different kernel, where MAC is implemented from the ground up.
Equating MAC to jails also shows you simply don't understand what MAC is.
If your webserver is compromised in a jail, can the webpages still be defaced? Yep. Not with a proper MAC policy.
Running third party software that the OpenBSD team did not audit themselves which gets pwned? Far less likely with MAC. If the machine is exploited, minimal damage can be done.
Need to restrict access from root to satisfy legal or policy requirements? Not possible with the outdated root = god model. It is possible with MAC.
Want to restrict the permission a process has, instead of automatically granting it the same full permissions your user account has? Not possible on OpenBSD, possible with MAC. No, systrace doesn't cut it.
The industry is slowly heading in implementing MAC in some form, because DAC (Discretionary Access Control, the current standard) is simply inadequate. It's not all SELinux, Microsoft have Windows Integrity Levels where low privileged processes can't write to higher level processes, Ubuntu has AppArmor etc. The industry is heading in this direction because we realize that allowing all programs to have the full set of permissions equal to the user it is running as is not ideal.
The OpenBSD team stand out in their flat our rejection of the very idea, considering it to be too complex (does not have to bee, see SMACK, Tomoko or AppArmor), or horribly understanding it to the point they equate it with an ACL. IIRC Theo has said in several interviews it is basically security theater and not useful, which is just ignorant. Given they tend to actually ignore security vulnerabilities and argue rather than admit and fix them, the project doesn't seem that security focused to me.
Sorry, but I will take a fairly secure system that grants me the granularity to protect myself in the case of an attack, as opposed to a system which claims awesome security because it comes with almost no current software and nothing running by default.
Re:OSNews? Thom Holwerda? Seriously?
on
OpenBSD 4.8 Released
·
· Score: 2, Insightful
Thanks, I found the mitre one pretty useful.
Most look like early DoS attacks, I would hope they have sorted that out now, and there doesn't seem to have been one since 2006. As for the rest, well SELinux runs in the kernel, so with the right kernel vulnerability yeah it can be bypassed. Considering most vulnerabilities are not kernel level but userspace....I'll gladly take that extra protection, of which no equivalent is offered on OpenBSD.
You don't have to configure a damn thing, but I like to.
I have it set so that my mouse wheel controls volume (default is seeking IIRC), double clicking wills witch between fullscreen and one click will pause. I prefer these settings over the defaults, but the defaults are perfectly fine.
Trust me, smplayer is just as easy to use if not more so than VLC, and yes it has an excellent easy to access EQ.
Mplayer will also play absolutely any file....without indexes, any codec...whatever. It is equal to VLC, if not better as it had a head start, and is a native desktop media player, not a videolan client.
Mplayer works fine on older os's, and since it is purely command line(although there are gui's for it) it has to be the least resource intensive player there is. I carry around the windows exe on a USB stick, and it can play absolutely anything I have every thrown at it without taking up space. It also has a variety of outputs both audio and video it supports, far more than vlc iirc.
For windows, I suggest you check out smplayer. I have found it far more configurable, and really like the ability to set a key or mouse event to absolutely anything you can do in the player. Let me know what you think.
I've been away for a few years, but I thought things are nto so much better.
iinet has a 1tb quota plan, but that is broken down into 500gb peak and 500gb offpeak, and the 500gb limit is up and down....so its more like 250 peak and 250 offpeak.
And, that plan is rare. Why do we need such a limit imposed on us, at all when most countries don't?
Most central American countries despite being developing have better internet than Australia.
Slashdot Mirror
Wow kid, you've got issues.
*PLONK*
HI. No, that isn't what I am arguing. I am not arguing MAC vs integrated cryptography, I am saying the OpenBSD team is falling behind by continually rejecting MAC in all it's forms and need to catch up if they still want to be known as a secure operating system.
You know Mac != MAC right?
See, you are a troll. Your argument in the OBSD post was simple zealotism without understanding what you are saying, as evidenced by your lack of a reply. Then you couldn't let go and troll with the same shit in a completely different thread. Funny :)
I should have known from your original response you were just a troll.
No one said anything about OS X using Linux, that I can see.
I understand you don't have a great understanding of security practicies, so let me enlighten you. MAC is great as an additional layer of protection and enforce least privilege. That doesn't mean we should ignore security vulnerabilities. Got it? Great.
Is that Android now dominates the Smartphone market. Thank fuck. The less dominance Apple have with their fucked up control everything for you polices only a good thing.
I don't know much about these platforms, but Android is based on Linux yes? SO would many of these vulns still be in Linux?
I was not being funny :|
I'm not confusing anything. This paper shows Chrome still lacks full ALSR support, although I admit I thought it was more than just that one DLL. Nice to know about the proper protected mode stuff though.
Chrome does not have full ASLR, several of it's libraries do not have support making it useless. Can you show how it uses Windows Integrity Levels?
I never said DEP, ASLR or MAC are unique to Windows, but IE is the only browser making full use of these basic technologies.
For all the flak IE gets, it's actually a great browser. We all know Microsoft make great products and often take the lead when forced to, and now is no different.
It is also the most secure browser by far, what with its inherent use of MAC, and full DEP and ALSR support. Strange, but true.
For varying definitions of compromised, you mean? If the Sysadmin has deployed a detailed MAC policy.
Nope, not at all. Regardless of if you use AppArmor, RSBAC, SELinux, Tomoko, SMACK or GRSecurity, it is trivial to deny write access to files from a user who owns them. It doesn't have to be a detailed MAC policy, and the only time that won't hold true is if there is a remote kernel exploit. Which...is pretty rare.
This is a good argument, but it's really hard to just say "Far less likely with MAC". This is always going to be the System Administrators responsibility. In fact all aspects of system security are going to be delegated to the system's managers almost immediately. This is the point where YOU need to decide if OpenBSD will suit your needs or become to complex to manage for your particular task.
I think you are getting away from my point by saying that all security is ultimately the administrators responsibility. I agree, and OpenBSD only provides basic unix permissions to enforce this. I am aware of the other stuff such as ALSR, but it doesn't come close to MAC. It's all based on stopping exploits, and there is very little in the way of dealing with a successful exploit.
This is goofy, I'm not sure I can think of a *nix system that doesn't allow you to disable root. On the other hand, I believe this is correct, with the exception that I don't believe there are any legal governance bodies in operation currently defining a proper MAC policy and implementation. Meaning that you could never prove OpenBSD was actually capable of meeting them or not, neither can you prove that SELinux meets these requirements. We only know that it did not happen while that government body was in place.
Any Linux system has multiple MAC implementations in the kernel, so they allow this. As does FreeBSD via TrustedBSD. It is an import step in implementing proper separation of duty.
Setuid, of course systrace will run right over setuid, but anyone who can set policy on a MAC system is a point of privilege elevation as well.
Setuid is not at all the same thing, and is arguably worse as that process then inherits the full complete rights as the user it is running as. If I want to launch a process as administrator because it needs to bind to a low port, that does not mean I want it to have write access to /etc.
Additionally, it is not true that anyone who can set policy on a MAC system is at a point of privilege elevation. Generally the user account to administer a MAC system is a standard unix account, which must be hacked in addition to the root account. The root account can do nothing to the MAC permissions and the normal user can do nothing useful except with its own files.
I can't believe you got modded up. MAC is not bolted on at all, it is a kernel patch. This means you end up with a different kernel, where MAC is implemented from the ground up.
Equating MAC to jails also shows you simply don't understand what MAC is.
The industry is slowly heading in implementing MAC in some form, because DAC (Discretionary Access Control, the current standard) is simply inadequate. It's not all SELinux, Microsoft have Windows Integrity Levels where low privileged processes can't write to higher level processes, Ubuntu has AppArmor etc. The industry is heading in this direction because we realize that allowing all programs to have the full set of permissions equal to the user it is running as is not ideal.
The OpenBSD team stand out in their flat our rejection of the very idea, considering it to be too complex (does not have to bee, see SMACK, Tomoko or AppArmor), or horribly understanding it to the point they equate it with an ACL. IIRC Theo has said in several interviews it is basically security theater and not useful, which is just ignorant. Given they tend to actually ignore security vulnerabilities and argue rather than admit and fix them, the project doesn't seem that security focused to me.
Sorry, but I will take a fairly secure system that grants me the granularity to protect myself in the case of an attack, as opposed to a system which claims awesome security because it comes with almost no current software and nothing running by default.
Thanks, I found the mitre one pretty useful.
Most look like early DoS attacks, I would hope they have sorted that out now, and there doesn't seem to have been one since 2006. As for the rest, well SELinux runs in the kernel, so with the right kernel vulnerability yeah it can be bypassed. Considering most vulnerabilities are not kernel level but userspace....I'll gladly take that extra protection, of which no equivalent is offered on OpenBSD.
Yeah, that's not a flaw in SELinux. Nice try though.
Can you find me an example of a hole in SELinux? Even one? I don't mean a flaw in policy affecting some distros, but an actual flaw in the subsystem?
You don't have to configure a damn thing, but I like to.
I have it set so that my mouse wheel controls volume (default is seeking IIRC), double clicking wills witch between fullscreen and one click will pause. I prefer these settings over the defaults, but the defaults are perfectly fine.
Trust me, smplayer is just as easy to use if not more so than VLC, and yes it has an excellent easy to access EQ.
Just give it a shot, you won't regret it.
Since when is $99 99 euros? An $140 android phone is not is impressive.
Mplayer will also play absolutely any file....without indexes, any codec...whatever. It is equal to VLC, if not better as it had a head start, and is a native desktop media player, not a videolan client.
Mplayer works fine on older os's, and since it is purely command line(although there are gui's for it) it has to be the least resource intensive player there is. I carry around the windows exe on a USB stick, and it can play absolutely anything I have every thrown at it without taking up space. It also has a variety of outputs both audio and video it supports, far more than vlc iirc.
For windows, I suggest you check out smplayer. I have found it far more configurable, and really like the ability to set a key or mouse event to absolutely anything you can do in the player. Let me know what you think.
I never understood why VLC bcame popular. Mplayer played far more formats first is more lightweight and had a windows port available since the start.
Wow, that's crazy. Why do they offer it if others don't? Don't they still buy their internet from Optus or Telstra?
Unlimited, or Unlimited*?
Only during off-peak?
I've been away for a few years, but I thought things are nto so much better.
iinet has a 1tb quota plan, but that is broken down into 500gb peak and 500gb offpeak, and the 500gb limit is up and down....so its more like 250 peak and 250 offpeak.
And, that plan is rare. Why do we need such a limit imposed on us, at all when most countries don't?
Most central American countries despite being developing have better internet than Australia.
these caps are such arbitrary bullshit.
It's worse in Australia, where a cap is often effectively 10gb down(20gb combined).
The limits ISP's have are nowhere near the limits they artificially impose on customers.
It's crappy collaboration between big parties and should be stopped by regulatory government agencies.