Slashdot Mirror
OpenBSD 3.5 Reviewed
eeg3 writes "NewsForge has a review of OpenBSD 3.5. It encompasses a fair amount of information, more specifically it details security, cryptography, installation, and new features." While not afraid to point out OpenBSD's shortcomings as a desktop OS, it's still a good tour of possibly the most secure OS. NewsForge and Slashdot are both owned by OSDN.
Every time there's a story about a vulnerability in something Microsoft related, there's a ton of modded up comments to the tune of "people should use Linux and related stuff to be more secure." But if security's such a BFD, why isn't BSD more popular around here?
"Derp de derp."
If you are running a server, and security is extremely important, there is nothing better than OpenBSD. Period, end of discussion. Banks and financial institutions should not be using Windows, Linux, or even FreeBSD servers: they should be using OpenBSD servers. Likewise for any website online trafficking in sensitive financial information and private information.
For websites that don't deal in such sensitive information, OS' that are less secure are acceptable, such as FreeBSD and various Linux' suitable for servers (Slackware, Debian, Gentoo).
For Desktop users, security isn't as paramount. However, it is still important, especially if you store any sensitive information on your computer. Some people store their private financial information on their computers. This is why Windows creates problems. Other Windows security problems are just obvious: the plethora of virus', exploits, worms, etc etc etc. These are areas where Linux is better (if not misconfigured so as to be insecure). The reason for Linux and not OpenBSD is because computer's are not an end in themselves. They exist to do certain functions; many of the daily things which people want to do on their computers just aren't possible to do on OpenBSD, or are a real pain, but are possible to do in Linux.
Stating people should use Windows, MacOS, Linux, or xBSD is over-general. Do you know precisely what every users' needs/desires are? No. Then how can you possibly say what OS they should use? The answer is you can't.
Of course, I haven't really responded to your question "if security's such a BFD, why isn't BSD more popular around here?" The answer is that security isn't considered paramount, above all else. If you wanted to be completely secure with your computer, you could unplug it from the internet and never plug it back in, and lock it up in a vault-room, with finger-print protection. People here probably consider other things important as well...
social sciences can never use experience to verify their statemen
"bombshell", "complete disarray", "bleak future", "river of blood", "endangered", "abysmal", "corpse", "charnel house", "dim", "decay", "Nothing short of a miracle could save it"
so, um, how do you like its chances?
p.s. -- nothing wrong with that parrot, it's just sleeping.
This problem can be avoided by just not going to any pages which end in ".php". That way you can ensure that the pages were crafted by professional programmers and nobody will try to exploit your uber-secure OpenBSD Javascript debugger.
Could you provide examples of "real operating systems designed to be secure from the ground up"? I'd like to know.
How can you call something "the most secure OS" when there is still a concept of a root user that has access to the entire system?
How can you secure, and be sure something is secure if the system can deny you from making sure it is so? Isn't that sort of a catch 22?
"real secure operating system"
What would you consider to fall into this category.
PS: Mac, and I believe Linux with the NSA patches(maybe, not?!) gets rid of the 'root' concept, and just uses sudo/su for doing former root-only tasks... Very good design, in my opinion.
Well, my understanding is that the most common exploits are simply bugs in userland and kernel code.
Even if one of these exploits leads to a remote or local privilege escalation, arguably it is the original exploit that is the real problem, since it led to the privilege escalation in the first place.
Furthermore, there is a fair amount of work being done to place all daemons on OpenBSD in a chroot jail, basically making running things like a mail server or http server no less secure than running without, which is a huge win for admins.
So, all that ACLs might give you is protection against local privilege escalation from the shell, which is nothing to sneeze at in principle; though the OBSD developers have been quick to suggest ACLs as offering minimal protection for the work involved. The consensus seems to be that there is more important work to be done elsewhere, like ensuring that a non-priv process isn't elevated to root. Though, this has not stopped others from thinking about this.
I'm also interested in what other altenatives you consider more secure, and if those alternatives are free-as-in-speech such that I can use it for a simple edge box for my internal network. I'm curious what other people are using.
-- clvrmnky
Trusted Solaris from Sun and SecureOS from Secure Computing used in their Sidewinder firewall are just two off the top of my head.
It doesn't necessarily need to be commercial either since there's TrustedBSD for instance. I guess I shouldn't say "designed from scratch" since many of them build on original BSD or System V code as a starting point, but there are certainly MAC based systems built from scratch out there.. probably custom jobs unavailable to us outside the government, but they're out there.
Again, I'm not saying OpenBSD is insecure, far from it. OpenBSD is probably the most secure operating system you'll get without introducing complicated mandatory access controls (type enforcement, RBAC, whatever you want to call it), but we shouldn't kid ourselves by saying that it's as secure as other operating systems available.
It's not true that OpenBSD does not support network installation of packages with automatic dependency handling.
Try this (assuming a Bourne-style shell):
All dependencies are discovered, downloaded, and installed as necessary. The only real downside is that you need to know the version of the package.
Check pkg_add(1) for the details.
Having one user (root) with the ability to do anything (s)he wants to the system is a security fault if only because it means *1* password will allow a person unfiltered access to your system. (there's more downsides, but it's almost 2:30 in the morning, and I'm farging tired) That's a single point of failure, which is not a great thing in the real world. It is to me, tolerable, but it is still a security fault.
Even then, you need to know the name of the first user that is in wheel before you can get in and try to become root.
I am not seeing a security problem, because it is not a single point of failure as you describe.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
Yes, and some methods of security can turn into unmitigated disasters when something goes wrong and you dont have a root capability to get access to fix it. It is always necessary to balance security against reliability and maintainability, and ideally maximise them all, a tall order with present-day technology.
My mistake (considering the time, that's hardly surprising) I meant you just need physical access (not hard) + 1 password for most locations, or on the other hand one good exploit.
That's one point of failure. Also of course "good" exploits on *nix tend to give the user root access, without a root to be given access to, there's not as much of a problem.
A third possible security situation with root would be if you work with the government, or for *SOME* banks that do not like the idea of a superuser. For some situations they do *NOT* want any one person to have access to everything, to them that's a security issue. Usually this only involves secret/top-secret or higher clearance, and will not be found in the "real world", but it's still a valid security point. Of course, you'll note I was just explaining some reasons why the previous user said it was a security problem...
As we were discussing OpenBSD in this article, the good exploit you refer to is a buffer overflow, I will point out that such buffer overflows don't work on OpenBSD. They just kill the daemon off. That's what the stack protection in OpenBSD is for.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
Delegating administrative privileges can be controlled with extremely fine granularity using sudo, as this excellent series of articles point out.
Here is a relevant quote from the first article:
Once you have sudo configured correctly, you can change the root password and not give it to anyone. Nobody should need the root password if they have the correct sudo permissions, after all! Reducing the number of people who have the root password can help improve security.
Comment removed based on user account deletion
A very Gödelian problem.
PS: Mac, and I believe Linux with the NSA patches(maybe, not?!) gets rid of the 'root' concept, and just uses sudo/su for doing former root-only tasks... Very good design, in my opinion.
root never really goes away. su and sudo work by switching to user id 0, which is the user id of root. What you can do however, is remove root from existing as a user. The kernel/whatnot still grants specials priviledges to user id 0, but you can't actually login or use any user with that id because root doesn't exist now! (I suppose this might have been what you were saying...)
Actually, you can't have su without a root user anyway, since su needs to authenticate you as user, such as root.
sudo can be a bad too, like if you are using ssh. Many systems have ssh deny remote login of root by default. This means you need a user password (often this user needs to be wheel which is gid 0) + the root password to su to root as. Two different passwords are harder to acquire than one is.
Although, I'll admit here and now that I use normally sudo.