Slashdot Mirror
OpenBSD Gains Privilege Elevation
ocipio writes "OpenBSD's systrace now has privilege elevation support. This means binaries no longer need to be suid or sgid an longer. Applications can be executed completely unprivileged. Systrace raises the privileges for a single system call depending on the configured policy."
...and isn't being able to run binaries unpriviledged a security hole, or am I just not getting it?
Yes
This article is clearly over most slashdot readers' heads. 50% of the comments are asking what this means, and the other 45% are asking if this is a security flaw. Figures. With KDE and RedHat, you no longer have to be smart to run UNIX. tisk tisk, what a shame.
Of course, I am biased as I run this fun little operating system on a produciton machine. 20 days away from one year uptime *ahem*. Ok, maybe that's not that great but it works well for me.
I am glad to see that the team has forged ahead and taken a step that UNIX style operating systems have needed for quite some time. This is a wonderful step in the evoluction of security that ALL of *BSD/Linux/etc. should implement without delay. At least from an administrator's perspective, I think this should be the norm.
For those that are unfamiliar with OpenBSD, it is a derivative of BSD that focuses its efforts onto creating a secure system without bells and whistles.
As always this is my opinion..
how is this better than setuid, setgid? At least with setuid and setgid, control over system privileges is given on a per-application basis.
Which do you think is more secure? Given a choice between having an application run as root [with all the attendant problems that this entails especially if a security problem is found in the app] versus giving the application minimal privileges [specifically all it needs to get the job done and nothing more], how could anyone think the setuid and setgid approach is better.
The difference between both approaches is the difference between a sledge hammer and a surgeon's scalpel. In fact the only downside to the minimal privileges approach, is performance and efficiency. In this day and age where one can buy half a gig of memory for around $100 and 3.0 GHz processors are on the horizon it really is time for us to adopt techniques for building secure software that have been known for decades but unimplemented due to performance/efficiency concerns.
Normal unix daemons (apache, bind, whatever) are started as root, and DOWNGRADE their permissions when they can.
This systems lets them start unpriviledged (not running as root) and the kernel will upgrade the permissions on a strict need-to-have basis.
Why give a mile when you only need an inch? That leaves a whole lot of room for error... This eliminates that problem.
Once again, OpenBSD takes the next step towards a more secure UNIX. Only they have the bravery to touch code thats 2 decades old, modernize it with well thought-out changes, and stand behind it. Not to mention that this is code that if screwed up, could reak havok. If anyone is qualified todo these things, the OpenBSD team is.
WOohoo!
hehe, I love slashdot.....
In fact, even for OSes that start out with lots of different privileges, it's far from clear that it helps--programmers seem to have trouble understanding all the implications of all the different bits. For example, VMS, with its much-vaunted mess of security bits, ended up succumbing to a domino effect: you get one bit, then using that, the next one, then one more, until you can do whatever you want. The trouble is that when you tell a programmer that his code runs with "restore from backup privilege" (an example from a privilege happy OS of yore), they assume that's all they get and don't even consider all the other weird implications that that privilege may have. And who can blame them? Who can keep all the weird effects and interactions of dozens of different privileges in their head?
The simple UNIX privilege system is good: when programmers write code that runs as root, they know exactly what that code can do: everything. And they try to take appropriate care.
Adding layers of easy to by-pass security is never a solution. Even if the crc and the program that checks crc is on read-only media, the system can still be fooled. The only solution is to put all of the binaries on read-only, but then there is no need to have the crc check.
Say no to software patents.
like that (overwriting will not change the inode) ?:
cp apache apache.tmp
cat rogue_executable > apache
And what privileges do you need to overwrite the apache daemon on your boxes?
I know it's root on mine.
This system won't protect you from someone who has root, but it will help prevent it from happening.
Consider the sendmail daemon...
It needs to bind to port 25, and write to people's mailboxes. What if you can restrict it to just those functions?
It makes it much more unlikely that sendmail could be used for nefarious purposes.
And with a modern sendmail, you only need root for the daemon to bind to port 25. If that's all it can do I;d love to see someone get root from there.
This is indeed a HUGE step forward...
Java's one of the few programming languages that has security built in from the ground up.Wich makes me really wonder why the .NET runtime environment doesn`t do the same thing? .NET attachments/client side code then these things would no longer be able to mess up the system.
That`s something I would love microsoft
to "inovate", if outlook and internet explorer would only accept
Likely they would not even be able to send mail to addresbook members like they could if you solved the outlook problem the "traditional" unix way ("runas" oulook as a low priv user).
An effective management system needs a heirarchy to direct and control it, "too many chefs spoil the soup".
In Canada we choose representatives, who then as a group run the country without any real requirement for further consultation. For most people the democratic process ends after election day.
Yes the ongoing stuff afterwards and the threat of not being elected, and protests are part of it too. But basically we choose our leaders, then they do what they want with little or no input from us.
True security will never be achieved in the *nix way (Complicated ACL's attached to every 'command' or 'system call'), due to problems such as The confused deputy.
True security can only be achieved when there is complete identity between what requests a process can express, and what the process is authorized - only possible without a global namespace such as the set of system calls or the file system. Only capability systems are of this nature.
OpenBSD may be secure in the sense that it has few bugs, where almost every bug in the every-growing code base regarding *nix security is a security hole, but its not secure in the sense that truly secure systems such as EROS are secure - by having (to sum it up):
A small, finite, debugged code base that deals with security - and no extra security code.
Simple security paradigm with a single simple-logic security test per request.
Identity between what a process can request, and what the process is authorized to do.
Fine-grained access control, with each process having capabilities to the exact objects it needs to access.
Mathematically-found model, that has mathematically provable properties.
The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).
Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.
No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.
I'm not very knowledgable on *nix security, so please help me out here. Why could you not simply do this trick to any program? IE: make a fake libc.so that erases all the files on the hard drive on a call to fopen(), and then run a program that has suid root?
root or setuid root generally ignores LD_PRELOAD as a rule on most unixen. Made it hell for Sun on their initial rollout of Sunrays, which used an LD_PRELOAD hack on yes, libc.
The Windows NT security model is far, FAR superior to anything Unix has. The design of the thing is fabulous. The problem is, it's hardly ever used, it's been made practically or totally impossible to use by an admin by using the interface, and of course, there's the bugs, bugs, bugs...
I've finally had it: until slashdot gets article moderation, I am not coming back.
At least in the case of MacOS X, it's not Mach. It's a stripped down version of Mach with a BSD personality. And only that personality. It incorporates a large amount of BSD's kernel and userland.
It's as BSD as NetBSD/OpenBSD/FreeBSD are. It's BSD.
Windows, on the other hand, would be Windows with a BSD compatibility layer.
To quote Apple on the subject:
"The stability of Mac OS X begins with Darwin, an Open Source, UNIX-based foundation. Darwin is a complete BSD UNIX implementation, derived from the original 4.4BSD-Lite2 Open Source distribution. Darwin uses a monolithic kernel based on FreeBSD 4.4 and the OSF/mk Mach 3, combining BSD's POSIX support with the fine-grained multithreading and real-time performance of Mach."
Now, repeat after me: "BSD is an operating system, not a kernel."