OpenBSD 4.8 Released 176
Mortimer.CA writes "The release of OpenBSD 4.8 has been announced. Highlights include ACPI suspend/resume, better hardware support, OpenBGPD/OpenOSPFD/routing daemon improvements, inclusion of OpenSSH 5.5, etc. Nothing revolutionary, just the usual steady improving of the system. A detailed ChangeLog is available, as usual. Work, of course, has already started on the next release, which should be ready in May, according to the steady six-month release cycle."
How are upgrades handled? (Score:1, Interesting)
I'm curious. Having never used a BSD-based system, how are upgrades managed? I understand that instead of installing packages, one uses ports. My impression of that is that you run a file in a ports directory and it compiles the software and installs it. Correct me if I'm wrong.
But how does one upgrade from, say, OpenBSD 4.7 to 4.8? Is there a script that is run that downloads and installs the appropriate files, or do you have to backup and install the new version on your system?
Re:OSNews? Thom Holwerda? Seriously? (Score:3, Interesting)
Insightful? Really?
The point of the article is that while the base system may indeed be very secure, it is practically useless. When needing to perform real world functions, the ironclad security of the base install is not all that useful. It's true that providing a good base on which to build your platform is important, however it's not nearly as important as one might think.
For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack. Is lighttpd any more secure on OpenBSD than on Linux? No. All you get with OpenBSD is that it's far less likely that there will be a local security exploit to chain with the lighttpd remote exploit. But with SELinux, you can get an even higher level of security. With SELinux, you need not only a local privilege escalation, but a hole in SELinux as well.
I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.
I would be absolutely ecstatic if OpenBSD implemented something more like SELinux in terms of privilege separation.
ACPI features? Best of luck then (Score:2, Interesting)
Re:Have they decided to implement security yet? (Score:4, Interesting)
OpenBSD's claims are based on clean code, well-written documentation and sensible defaults, not a baked-in or bolt-on MAC system (which in this case stands for Mandatory Access Controls.)
Because it can be bolted-on, it's not really a criticism of the OS itself. To be fair, jails gets you 90% of the way there - MAC systems were hot stuff on multi-user systems, but most Unix installations these days are single-seat workstations or back-end servers in the new "appliance" model which don't have any human users at all apart from the admin. Applications can be effectively protected from each other with jails... so an elaborate MAC system is kind of a waste of time in most cases. Maybe in a few specialized file-server scenarios, it might come in handy... but it's pointless for a box running a LAMP stack.
Oh, wait, OpenBSD doesn't run jails, and the devs tell you to screw off and die whenever they're asked about it.
I suppose they still have clean code and sensible defaults. You just need to buy a new server every time you want to isolate applications from each other.
But this isn't actually a security issue, this is a developers-up-their-own-fundament issue.
Re:OSNews? Thom Holwerda? Seriously? (Score:3, Interesting)
You're forgetting the difficulty of a successful exploit in the first place. OpenBSD was the first OS to implement ASLR, for example (http://en.wikipedia.org/wiki/ASLR). Linux only has fairly weak ASLR built in. There are a few other differences. Yes, the value of things like SELinux or AppArmor is considerable, and it would be great if OpenBSD implemented such a sandboxing capability, but your argument that the security of the OS itself isn't also very important is incorrect.
Re:fdisk (Score:3, Interesting)
Re:OSNews? Thom Holwerda? Seriously? (Score:2, Interesting)
I'm sure you're not talking about Unix because Unix was never designed with security in mind and it's ridiculous to think that security was even a consideration in 1970
Yeah it's kind of funny how people keep talking about how secure unix systems are and how superior they are when they aren't.
Unix was a watered down Multics.
http://en.wikipedia.org/wiki/Multics [wikipedia.org]
Security was a major consideration in Multics in 1970 and even earlier. Unix on the other hand had different objectives.
Re:fdisk (Score:3, Interesting)
You can say "the targeted users have no problem with it", and that's fine, but that pool of targeted users is bound to shrink over time (again that's fine, but many would see that as a bad thing, worth some compromises to avoid)
Re:Have they decided to implement security yet? (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.
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 [coresecurity.com], 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:Audio on BSD? (Score:5, Interesting)
Re:fdisk (Score:3, Interesting)
I had no problems installing Debian potato. Still, I prefer today's installer. Your point being?
Re:fdisk (Score:1, Interesting)
Funny, but the targeted group of users I hang around with like to learn new things if they're confronted with something new. Perhaps the targeted group of users you hang around with does not.
Re:Have they decided to implement security yet? (Score:2, Interesting)
If your webserver is compromised in a jail, can the webpages still be defaced? Yep. Not with a proper MAC policy.
For varying definitions of compromised, you mean? If the Sysadmin has deployed a detailed 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.
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.
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.
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.
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.
Setuid, of course systrace will run right over setuid, but anyone who can set policy on a MAC system is a point of priviledge elevation as well.
Re:Suspend/Resume? (Score:3, Interesting)
That's actually a great reason to use it on laptops (even if the pull of Ubuntu was too strong for me). A laptop without the password to the encrypted boot system and without any way to get it out of sleeping without knowing the login password might as well have a formatted drive for all the use it is to a thief.
Yes, you can get most of that with a properly set up Linux system. That's what I'm banking on with my own laptop here. Still, should it get stolen, I'd feel a lot better if my personal data was locked up in OpenBSD.