Slashdot Mirror
OpenBSD 4.8 Released
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."
Kickass.
Hey buddy, can i bum a karma? ~}CinderellaManson{~
Does their installation fdisk still suck?
You're taking some random blog article linked to by Thom Holwerda at OSNews seriously? Those are your three strikes, and you're out, my friend.
Look, the OpenBSD team knows exactly what they're doing. They're some of the brightest minds in the field. They have many years of experience with real-world security. They've been around long enough to know that there are something things that sound totally fantastic in theory, but in practice they're a complete failure.
Many advanced security approaches fall directly into this theoretically-great-but-actually-quite-shitty category. They end up being difficult to implement, and end up being full of security flaws and other holes. They end up causing the very things they're supposed to avoid! Thankfully, the OpenBSD developers know this, and smartly stick with a model that's been proven successful over the couse of 40 years.
Someone forgot the infamous song release for 4.8 to be included in article details: El Puffiachi
The release song doesn't even have lyrics :-(
How good can the release be then, I ask!
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
To spare this section of all the trolls (yeah right!), I have incorporated every *BSD troll into this one message. Thank you.
The *BSD Wailing Song
What's left for me to see
In my ship I sailed so far
What can the answer be
Don't know what the questions are.
And after all I've done
Still I cannot feel the sun
Tell me save me
In the end our lost souls must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low.
Who knows what's really true
They say the end is so near
Why are we all so cruel
We just fill ourselves with fear.
And heaven and hell will turn
All that we love shall burn
Hear me trust me
In the end our lost sould must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low
Final curtain
Final curtain
pressed to bsd lips
bsd drink up
I don't want to start a holy war here, but what is the deal with you BSD fanatics? I've been sitting here at my freelance gig in front of a BSD box (a PIII 800 w/512 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this BSD box, the same operation would take about 2 minutes. If that.
In addition, during this file transfer, Netscape will not work. And everything else has ground to a halt. Even Emacs Lite is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working on various BSD machines, but suffice it to say there have been many, not the least of which is I've never seen a BSD box that has run faster than its Windows counterpart, despite the BSD machines faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 800 mhz machine at times. From a productivity standpoint, I don't get how people can claim that BSD is a "superior" machine.
BSD addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a BSD over other faster, cheaper, more stable systems.
It is common knowledge that *BSD is dying. Almost everyone knows that ever hapless *BSD is mired in an irrecoverable and mortifying tangle of fatal trouble. It is perhaps anybody's guess as to which *BSD is the worst off of an admittedly suffering *BSD community. The numbers continue to decline for *BSD but FreeBSD may be hurting the most. Look at the numbers. The erosion of user base for FreeBSD continues in a head spinning downward spiral.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major marketing surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.
Fact: *BSD is dying
It doesn't matter, no matter how many time you try to recesitate *BSD, it's just does
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?
They have suspend/resume now?
I guess this will be the Year of the OpenBSD Netbook!!
It is good to call attention to features that need work.
It is better to contribute code towards the solution.
I hope they didn't break something when adding the ACPI features. From my experience, it is one devil of a specification. Just half an hour ago, I couldn't browse anything on my Ubuntu Lucid because I had changed one ACPI related setting in Bios, and XP failed to boot at all. I wonder how far-reaching and bizarre effects it has on other OSs, and in other scenarios.
It was funny =p
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.
From the article, about a "secure operating system":
> Generally, this would be taken to mean an operating system that was designed with security in mind, and provides various methods and tools to implement security polices and limits on the system.
Sadly most naive users still believe that security is about setting fine grained permissions, roles, resources and tagging system objects in general. In practice 1) security exploits simply bypass or reconfigure such validations or policies for their own purpose, and 2) getting a really good "fine grained" configuration and reconfiguration is pretty difficult, time consuming, and prone to error (i.e. to increase the vulnerability.)
If it's any indication, I met a BSD user at a 1998 LUG meeting, he had a full-on desktop with all the effects and audio going on a Dell laptop. So I imagine that if your hardware is supported (most likely) it should work fine. BSD has extensive documentation and lists of supported stuff. I'm a linux guy, so I really don't know more than that. Best bet is to just try it, IMHO.
C|N>K
www.openbsd.org slashdotted?
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.
If you ignore ACs because they are anonymous - you're an idiot.
OpenBSD performance is not something they advertise, for good reason. If there's a trade between security and performance, they'll take security. The most noticeable example is the malloc() implementation. This is much more aggressive than any other that I've seen at returning memory to the kernel. This means that there are a lot more system calls being made by OpenBSD libc in any program that calls free() a lot and a lot more page churn (meaning more TLB misses). This hurts performance (about a 5-20% hit, depending on your benchmark), but it means that use-after-free bugs tend to crash early, rather than becoming exploitable. If you're doing HPC, OpenBSD probably isn't the system for you, but they never claimed it was.
I am TheRaven on Soylent News
And there's a very good example of this. Windows NT has had fine-grained ACLs on every single kernel object (not just files - mutexes, sockets, processes - everything that the kernel is responsible for) since its creation. Until relatively recently, UNIX systems had a very coarse-grained security system; use/group/all permissions on files, no permissions on anything that wasn't a file (although a lot of things are in UNIX), one magic user that can bypass everything. Guess which one had more vulnerabilities.
To make matters more interesting, compare the Windows NT kernel with a Linux kernel - for pretty much any time period you pick, the NT kernel will have fewer security advisories. Nothing is bypassing these fancy security mechanisms, they're just not being used. In a lot of cases, Windows users were running as the highest-privileged used and running their apps with this privilege, in spite of the fact that the kernel supports much better policies.
A door is only a security mechanism if you remember (and understand how) to close and lock it.
I am TheRaven on Soylent News
OpenBSD has gone down the userspace sound daemon route, with aucat. This is much simpler than something like portaudio and provides userspace sound mixing. I generally prefer the FreeBSD approach (fully working OSS 4 compatible, with high-performance low-latency kernel sound mixing), but the OpenBSD approach (like everything else in OpenBSD) trades a little performance for a lot more security.
I am TheRaven on Soylent News
That's alright. I'll make the suggestion that /. adds the moderation ±0 Funsightful. :P
As a CJK user, I want to have Unicode supported on OpenBSD. Last time I checked, OpenBSD didn't have a support yet. Any news for I18N on OpenBSD 4.8 ?
A classic rant that is largely nonsense but does have a smidgen of truth. BSD's largest failing is that Linux was better at pushing people's buttons than BSD was. Linux has always felt dynamic, pragmatic and aggressive in pursuing new functionality whereas BSD is more laid back and feels like it is trying to preserve some archetypal Unix at the expense of progress. Over time that has meant that Linux has stolen an insurmountable lead. I think its very hard for something as large as BSD (in its most common open source forms) to "die". Instead its user base diminishes to a gnarly stump and then it carries on in this state indefinitely, barely ticking over, supporting a minimal user base but still alive. Look at GNU Hurd as an example of a project which isn't dead either but is certainly moribund. I think if supporters of BSD or Hurd wish to bring their OS to a wider audience they need to look at what made Linux a success and try to emulate it. Or continue bumping along the bottom indefinitely. One saving grace for BSD is its licence and what it means for commercial vendors. The Apples & Googles of this world see BSD as a means to develop open source code without being "infected" by the GPL. For example Android is virtually all BSD based in user land and it's not hard to envisage that even the kernel could be swapped if it came to it.
No, you insert the latest openbsd disc and choose upgrade instead at boot up. Upgrading while the system is running (like with apt-get) is unfortunately, a very manual process and I wouldn't recommend it due to the many mistakes one can do.
Change is certain; progress is not obligatory.
Others would possibly have OSSv4 implementations if the company didn't have a nutjob take on what the GPL means. At least one of their developers thinks that if you run a closed source app that needs sound like say Doom3 then you have to buy one of their commercial licenses. Even RMS doesn't have such an expansive idea of what the GPL does and does not do:
http://4front-tech.com/hannublog/?p=8
The really good part is in one of the comments posted by one of the devs:
The point is that we (4Front) are the owners of the copyrights of OSS. We have the power to define the terms for usage of OSS. The terms are that you can use OSS "for free" if you use it from GPLed applications. Otherwise it will be "for a fee".
And this is for a sound stack that is supposedly distributed under GPL terms. Last time I heard, writing to /dev/dsp is not linking. Since what they publicly say is in direct contradiction to the GPL, I take it to mean that ONLY their commercial licenses have validity.
Yes, they DO have the power to "define the terms of usage of OSS" but they DO NOT have the power to rewrite the GPL. Since what they want is a trialware license then they should remove the GPL boilerplate from their downloads and substitute such a license.
The opinions of 4Front are completely irrelevant to FreeBSD - their implementation of OSS 4 is independent of 4Front. 4Front does ship an OSS 4 implementation for FreeBSD, but it lacks per-channel volume control and AC-3 pass through while playing analogue audio, both of which are supported in the FreeBSD version.
I am TheRaven on Soylent News
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.
Hey buddy, can i bum a karma? ~}CinderellaManson{~
Disable bce(4) in i386 GENERIC and RAMDISK kernels.
Why was this removed? Makes my latop not useable with OpenBSD.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
I think the BSD licence is why the BSD OS is where it is.
Even Emacs Lite is straining to keep up as I type this.
The Internet was straining to keep up as you posted that.
(but it was a funny read!)
"A government is a body of people usually -- notably -- ungoverned." -Shepherd Book
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.
If you ignore ACs because they are anonymous - you're an idiot.
This should definitely be modded higher. Fine-grained security controls don't matter if nobody uses them correctly, and they introduce increased complexity in the codebase that makes more room for bugs to creep in. By comparison, OpenBSD may be much less user-friendly in most ways, but its emphasis has been "real-world" security from the beginning, with heavy code audits and good security defaults. Even if its security model isn't as advanced as some others (Linux, NT), its implementation is far better in most cases.
There's no place I could be, since I've found Serenity...
That was more than ten years ago, and OpenBSD is still the *nix OS that remains closest to the original Unix style and spirit.
Being a BSD variant it means it already started to deviate from the Unix way long ago, but with the notable exception of Plan 9 (not surprising given that the original Unix team were responsible for Plan 9, and by the way now are working on Go), all other *nix-like systems are much, much worse.
The quality of OpenBSD code is also much better than that of any other popular OS, and its developers are usually fairly good at restraining themselves from implementing popular 'features' that simply add complexity and no real value.
In short, if you like simplicity and quality, give OpenBSD a try, I'm still very grateful it was my first exposure to *nix systems.
"When in doubt, use brute force." Ken Thompson
In a sentence I will say that for example.
Engarde Linux vs OpenBSD would compete along different methodologies, yet, will both likely enjoy a good degree of success.
Hey buddy, can i bum a karma? ~}CinderellaManson{~
That is the battle you're discussing.
SELinux vs Integrated Cryptography.
I'm pretty sure they are both going to have trade offs.
Hey buddy, can i bum a karma? ~}CinderellaManson{~
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.
If you ignore ACs because they are anonymous - you're an idiot.
Wow kid, you've got issues.
*PLONK*
If you ignore ACs because they are anonymous - you're an idiot.