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{~
Can someone please repost the BSD troll-in-one? Or is it dead?
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.
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!!
too long; didn't read.
Hail Eris, full of mischief...
E pluribus sanguinem
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.
Spelended!
Love is love and OpenBSD is Love.
With kind regards.
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.)
How is BSD for Audio, I'm looking for a stable netbook audio workstation [Eee PC 701, 2 Gig] and all the small Linux distros I've tried have issues, and the tech help community's I've requested polite help through all seem to have an "attitude" of "do-it-yourself-lazyboy", is BSD a possible alternative?
I'd like to use it, not tinker with it all the time in an attempt to make it work, I'm looking for a Tool distro.
I come from the windows world as a super user, but Linux gives me a difficult time due to memory issues due to a brain injury, and so I need help when I can't find my own answer, and I do my best to look first, but I get either silence or hostility because I didn't find some obscure reference somewhere.
A couple of entries from this "detailed changelog":
# Fixed a bug in pkg_add(1).
# Improved acpibtn(4).
and so on. Are entries like this worth including? They're definitely not worth my time to read.
Is there nobody with the "release manager" hat at OpenBSD who cleans that up to remove useless entries like the two above?
www.openbsd.org slashdotted?
I haven't noticed that the system is very clean. It seems significantly more convoluted than the NetBSD design. The last time I needed a clean and simple BSD for an old 486, I tried OpenBSD first, and the installer was ugly as sin, crashed, and when I finally got it installed, it ran like a pig. A slow pig, that is, and not a quick and athletic one. Then I tried NetBSD and installed that instead, and it was very simple and fast, just a vanilla and traditional Unix system without bells and whistles. In modern performance benchmarks as well, Linux, FreeBSD, and NetBSD are at the top, while OpenBSD really does poorly.
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
Read again, he didn't equate MAC to jails; he said despite the ability to use MAC, it doesn't support jails, and therefore for security you'd have to implement each 'jail' as a physically separate piece of hardware.
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 ?
does openbsd has something like apt-get upgrade?
You must be the only slashdotter with a brain in the last few posts.
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/
Ubuntu > BSD.... yeah baby!!!!!
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.
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
flask of ripe urine
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 doesn't matter. It's a plain and simple truth, *BSD is dying.
Click here [planetquake.com] to see the most appropriate case mod for a *BSD system.
If you can also print out your word processor documents on mu
Hey buddy, can i bum a karma? ~}CinderellaManson{~
Wow kid, you've got issues.
*PLONK*
If you ignore ACs because they are anonymous - you're an idiot.
> 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.
Um, what? I don't know if you are intentionally lying, but you are certainly not speaking truthfully.
I read the coresecurity.com link in it's entirety, and here's what I see:
* The bug was reported to the OpenBSD devs on Feb 20th.
* The developers fixed it the bug, and tested the fix
* The OpenBSD project made the fix generally available within six days (Feb 26th).
That's pretty good turn around time.