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."
I think you misunderstand.
The message referenced indicates that this is a security feature, which will allow the individual system calls to be executed with escalated privileges. This is an advantage in that you do not need to have the entire binary executed with the escalated privileges, and so reducing the number of potential privilege escalation attacks.
This signature carefully hand-crafted from recycled electrons.
systrace
It's fine grained control of privelege. This is to the basic unix concept of running as a uid and setuid what ACLs are to normal unix filesystem permissions. For a really simplistic example - with this you could run your apache binary with literally zero priveleges, like "nobody" (from start to finish, no run as root then drop privs), and the explicitly enable it to have root-like privs only for the one system call it uses to listen to port 80.
11*43+456^2
Probably. Years of IT have blurred the lines between jokes and cluelessness in others.
IHBT. I will HAND.
This signature carefully hand-crafted from recycled electrons.
It's not a bug, it's a feature !
For example the Apache webserver, it needs to be started as root, in order to bind to port 80. Now this is no longer required, since a call to the new function will allow it to bind to 80 as an regular user, provided that the syscall is configged to allow that.
Same goes for X, which now no longer needs to be run SUID.
It probably won't be long before these mechanism is common good, but I wonder what happens if someone finds an exploit in THAT ?
This sounds similar to a scheme that Java supports on some platforms (netscape?); I believe there is a setPrivilege() call.
I'd like to see more of this kind of thing- restrictions to the file space that 'parts' of programs can access should be made, as well as I/O and networking restrictions. Is an email worm going to happen if the OS stops the macros from sending mail? Why should it if somebody else wrote the macro? There's a clear need for better granularity of security.
We've seen how useful personal filewalls are for network interfaces- this needs to be extended to the other services that the OS supports.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"There are things that must run as root to work. The common way to allow normal users to do these things was to make them setuid, which meant that the application always runs as its owner, no matter who launched it. Yes, this can be a security hole if not configured wisely. Stuff that requires configuring network interfaces is a good example. This method allows an application to be run as joe_user, but still access privileged system calls, depending on configuration. It is less of a security hole than what is being done now.
"Proximity to wonder has blunted our perception and appreciation of it" --Tim Hartnell in 'Exploring ARTIFICIAL INTELLI
how is this better than setuid, setgid? At least with setuid and setgid, control over system privileges is given on a per-application basis. With this per-system call method, the kernel somehow has to track each system call made by an application and grant or refuse privileges on some basis. (On what basis is unclear from the article.) This seems like a lot of data for a kernel to keep track of, considering the number of system calls a typical unix kernel has.
Though I believe improvements to setuid, setgid is needed, per system call access privileges don't seem to be the right approach. I would much rather go with chroot jails for each application.
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..
What the original commenter was correct in bemoaning is that the quality of the discussion here on /. is degraded by the number of coments that give evidence to the fact that their authors are not familiar with the general subject matter and have not taken the time to do basic orientation before emitting. These comments add a much value to the forum as the endless Beowulf cluster chatter and the first post idiocy.
All my previous sigs now look like this one, I wish they were permanetly recorded when used.
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.
If a flaw is found in the syscall lookups (ie: an app can make a sequence of syscalls to give itself priveledged access anyway) doesn't this mean literally any executable is capable of ruining your machine as opposed to only the suid root ones on any other *nix OS?
Wouldn't a combination of both be better?
And you have to admit it would bring nice little change to the front page, and maybe a few more "WTF is this?!?" posts. Especially if it was the sub logo from here :-)
Yes... I'm a fanatic, now go away you insensitive clod.
What they're doing here is simple and clever. The idea is to run an executable, trap it's privileged system calls, and then create a policy file (call to uid map) from the run. After the policy is in place and the executable is run again, the system promotes the calls listed in the policy to the appropriate privilege level. Any new privileged calls generate an error, as they're most likely a security breach or some part of the executable that never got executed the first time.
b in_httpd.
A sample apache policy is here: http://www.citi.umich.edu/u/provos/systrace/usr_s
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!
This sounds similar to an idea I've floated around to a few people, except that my idea worked on library functions. The idea was to allow setuid and setgid on individual functions instead of entire programs. When you called such a function, it would run with the elevated privileges determined by the ownership of the library file itself, and when it returned, permissions would go back to what they were previously.
/etc/priv.conf can only be read by root). An attacker could execute a
The one issue I had with this was what to do if a setuid function called another function. Should the privileges be passed onto the extra function? At first thought, it seems like it should, but consider this example:
I have a library called libprivfunctions.so. Within this library is a function to open a privileged file:
FILE *open_priv_file(void) {
return fopen("/etc/priv.conf", "r");
}
We'll say this function is set to run as a setuid root (maybe
export LD_PRELOAD=/home/attacker/libc.so
before running a program linked against libprivfunctions.so. This version of libc.so would have a fopen that creates a root shell. When open_priv_file() is called, it will call the falsified fopen which, if run as root, will breach the security of the system. Maybe the easiest way around this would be to disallow any LD* variables when running programs linked against setuid/setgid functions (similar to the way setuid/setgid progams work). But the logic behind this gets complicated (you don't know if you're linking against setuid functions until after you've linked. But what if that outcome was caused by one of the LD* variables?).
I would say that allowing elevated privileges to just system calls is a good way around this problem. Hats off to OpenBSD for another sound decision.
For every post, there is an equal and opposite re-post.
This is the first I've heard of Systrace privilege elevation. However, it seems to address what has historically been one of the greatest causes of security problems in Unix.
If you look at the major vulnerabilities we've seen in Unix operating systems and software, they usually fall into one of three categories:
1) Bugs in the kernel.
2) Bugs in servers running with elevated privileges (often root).
3) Bugs in suid binaries (often suid root).
Privilege elevation could significantly reduce the problems caused by 2 and 3. It's by no means a silver bullet that's going to eliminate vulnerabilities, but it could produce a huge improvement.
Consider how difficult it is to write a secure suid root binary. Not only do you have to be extremely careful about your own code, you have to worry about possible bugs in any of the libraries you link with. Some people (e.g. D. J. Bernstein) seem to have the knack of producing secure code first time, but even a good programmer who is always thinking about security can make the occasional mistake.
With privilege elevation, such mistakes are no longer security disasters that grant complete root access to an attacker. The most an attacker can do is make the few privileged syscalls that are permitted by the systrace policy.
Lachlan.
Suppose a new Apache version starts up differently, so the previous policy no longer matches. Perhaps Apache won't change that much, but there are certainly some apps which would need more complicated policies than Apache; what if they read config files in a different order, or add some new wrinkle? What about Perl or Python programs, where some module changes, or Perl itself changes?
It would seem to me (as naive as I am to this new concept) that this could be a major pain in the butt. How much does this apply in practice?
Infuriate left and right
Somewhat similar capabilities also exist for Linux. The Linux Security Module (LSM) effort adds the ability to insert an additional access control mechanism into a Linux kernel (without a recompile). You can then at run-time insert a modules to add finer control over privileges. Several modules exist, such as SELinux. This approach makes it easier to experiment or create your own access control policy. There are various LSM modules already available; none of them are exactly like this, but most provide finer-grain control. There are definitely technical differences, too, but describing those differences would take up WAY too much space here.
There are definitely situations where finer control over privileges is very desirable. Which way is the best way is very much in doubt. The good thing about finer control is that you can give a program only the privileges it needs. The bad thing about finer control is that it takes more work to set up. "Learning" from program runs helps, but it doesn't fully solve the problem - there are usually many conditions that aren't triggered by simple runs yet can happen in real life.
Anyway, this kind of capability is a good thing. It will be interesting to see what happens over the years as people try out various ways to add finer control - the trick will be to add finer control while still keeping the system easy to administrate. It's not even clear that there is a single solution.
- David A. Wheeler (see my Secure Programming HOWTO)
I really hate to say it, but:
1) The story in no way credits Niels Provos, the author of systrace.
2) The story does not mention that this feature was added to NetBSD first.
I don't mean to claim "NetBSD is better" or anything, but at least say "OpenBSD and NetBSD" or "NetBSD and OpenBSD" or something, not "OpenBSD". Also, PLEASE credit the guy that did the work, eh?
For system services that change privileges based on some internal state (like authentication), sandboxing does not work very well. In that case, you want to use Privilege Separation.
On the other hand, if you have some global restrains, like root may never log in, you can use systrace to enforce them.
A combination of both methods will give you a good fit.
I hate to be a bitch here, but the feature was added to NetBSD first. I don't mean to imply NetBSD is better than OpenBSD, but maybe some equal billing would have been in order? And by the way, what happened to crediting the author of the code? The work was all done by Niels Provos, who's a damn good security guy.
"This means binaries no longer need to be suid or sgid an longer."
Doesn't Slashdot have any moderators who speak English? I'll gladly volunteer to read over the stories before you guys post them to the main page if it'll rid us of these ridiculous grammar, spelling, and style absurdities.
Hey, interesting idea, how about expanding the policy to include which system calls, which level, and the amount of times they can use them.
Don't know how CPU intensive, but after reading that Apache httpd ACL, you could really be anal and lock down applications. We currently use EFS on our Sun Boxes, and it locks down the boxes tighter than a drum. Sounds like a nice extension on a theme.
Niels Provos was an OpenBSD developer until recently. He's the same guy who did the PrivSep code for OpenSSH.
/ 10 /11/0039.html
It actually appeared in NetBSD first.
http://mail-index.netbsd.org/current-users/2002
Regular capability systems are more coarse grained. You can have capabilities that say this application is allowed to bind to a reserved port,etc. However, with privilege elevation in systrace, you have much finer control. The privileges are just elevated for a single system call matching specified system call arguments.
Additionally, with systrace you can reduce the privileges of binary applications without the need to add support for capabilities in the source code.
Except this change originated in NetBSD.
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
ACL's, MAC's and more http://www.trustedbsd.org/
http://www.apple.com/macosx/jaguar/unix.html
... Jaguar integrates features from state-of-the-art FreeBSD 4.4...
KLAATU, BORADA, NIh*ahem*
Using the executable file of the process would be dangerous because the attacker could use compromized shared libraries. Any passwords would require changes in the software (i.e. you'll have to recompile apache so that it could authenticate).
The only thing I can think of is a token in the process environment that can only be set by root (maybe an additional group ID). So apache would still have to be run by a program with root permissions (init script) to be able to listen to port 80.
I'll say it again: the change appeared in NetBSD first, so one should mention both NetBSD and OpenBSD here, and please give credit to Niels Provos, the author of systrace and thus the guy who's been doing all the hard work here.
The answer is you can't tell the kernel "I'm Apache." Obviously a mechanism that just let you do that would be trivial to evade. The kernel can easily know whether you are the apache program or not, however, because it knows the inode backing your executable -- there is no way to forge that. This is the same way the kernel knows that you have a suid bit -- it looks at the inode for what it is executing when it executes it.
The systrace mechanism is a very nice one. Most on-system exploits these days are caused by suid programs being exploited before they give up privileges (and many don't give up privs ever). By only giving a program just the privs it needs, you can avoid having to have root privs available to the programs at all. You can't exploit privileges you never have had.
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.
The URL describing this stuff is
http://www.citi.umich.edu/u/provos/systrace/
I've used ssh to rid myself of things like "su -l" and "sudo" before. I think the basic idea can be used to get rid of necessary suid/sgid programs with elevated permissions. The basic theory is each application is actually called by a wrapper using ssh. Public keys from the application's user or group (root, apache, wheel, etc.) are provided to a user with genuine need to access these apps and placed in the ~/.ssh/authorized_keys(2) file. Then the user's public key is provided to the application user's ~/.ssh/authorized_keys(2) file. When the user calls the application, they are allowed access using RSA key authentication. No need for blind SUID/SGUID apps as only those users who need to use it have the permission. Furthermore, these permissions can be easily revoked by a.)changing the app's private/public keypair without providing them to the user, or b) commenting/deleting the user from the authorized file. Additionally, with ssh-agent, keychain, and authorization forwarding, these priveledges can be locked down tight. I'm not sure if openssh authorization forwarding will allow the authorization to be okayed from a remote machine. Just a random thought that seems appropriate here. Let me know what you think.
--Wes
I always get the shakes before a drop.
like that (overwriting will not change the inode) ?:
cp apache apache.tmp
cat rogue_executable > apache
and the other 5% can't even add up.
Separating the various functions whose use should require privileges into catagories that can be granted individually (or in groups) to different userids is definitely a Good Thing: it probably won't eliminate the need for a super-user and a few godlike system maintainance users, but it allows the system administrators to keep the really dangerous 'own all data' and 'devour all resources' functions to be kept under tighter control than the all-or-nothing approach. (Arguably, you shouldn't even consider handling sensitive information on a platform that cannot administer privileges in a reasonably fine-grained way, but that's another argument.)
Security in UNIX can be messy. It is hard to add security late in the prosses without making it hard to use and understand.
EROS (GPL) was designed for fine tuned privileges from day one. This is a natural part of the capability system.
"EROS is a pure capability system. Authority in the system is conveyed exclusivly by secure capabilities, down to the granularity of individual pages."
This is a secure design and a OpenSource OS.
http://www.eros-os.org/
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.
Existing programs will assume that if a process demonstrates one privilege that traditionally only a root process posesses, then it must also have all the others
Assumptions cause trouble, lets assume that this buffer is "more than big enough for anything someone will put in there", that worked out REALY well didn't it?
A proper program should check for each individual requirement, and act appropriately. Bad code has lots of assumptions, an assumption is a bug that hasn't been found yet.
Most of my code isn't proper, I'm lazy.
In the interests of pedantry, it's actually ports below 1024.
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.
It's not about ACLs, it's about privileges.
.comPack works, which is an EAL4 (exceeding B1) kernel security addon for Solaris and AIX.
There are different kinds of philosophy regarding privilege management.
Granting privileges to binaries, authorizations to users
Trusted Unices commonly grant privileges to binaries, but only let the process use the privilege, when the user who executes the binary has got a certain authorization.
For example, there is one Authorized Privilege Set (APS) and one Privileged Authorization Set (PAS). You put the PV_FS_MOUNT privilege into the APS, and you put the MOUNT authorization into the PAS.
If the user who executes the binary has a MOUNT authorization, then the process gains the PV_FS_MOUNT privilege, and the user can use the program to mount or unmount filesystems.
If the user who executes the binary does not have a MOUNT authorization, then the process does not gain the PV_FS_MOUNT privilege, and therefore the user can't mount or unmount filesystems.
(This explaination is a bit simplified, because you would also have to look at the limiting privilege set or limiting authorization set, but that does not matter here)
This is how Pitbull
Granting privileges to users, running processes with adopted authority
The other way is to grant privileges to users, and then to let a binary run with the privileges of a specific user added to the privileges of the current user (Adopted Authority).
For example you put the ALLOBJ privilege into the privilege set for user 'John', and you give some binary an adopted authority from user 'John'.
User 'Mark', who does not have the ALLOBJ privilege, executes the binary, and the process gains (adopts) all privileges from user 'John', so user 'Mark' can run the program with the ALLOBJ privilege.
This is how the SLIC part of OS/400 works (SLIC is the operating system kernel of OS/400, running on IBM AS/400 computers).
[Tell me if I got something wrong here, I'm not an OS/400 expert]
Granting privileges to users makes administration easier and it's powerful enough for almost any scenario; granting privileges to binaries makes it a bit more difficult but also more powerful, and i guess that's why it is the preferred method used by Trusted Operating Systems.
But really, it needs to get out of the ivory tower and start giving us examples that work. The Confused Deputy is about compilation, sounds like it was an issue from a VAX box from the 80's, and not only is so utterly irrelevant to Joe User, it's not even all that terribly accessable a metaphor to people using gcc!
The erights folks are using more accessable examples (a web browser), but in their examples paint a picture of the land of popup hell, where every app has to ask to do every single operation. Write to one file, one popup. Write to another file, another popup. Open your address book, another popup. Experience shows that users click "yes" or "ok" on popup dialogs or whatever button they can just to make the damn things go away and make them stop coming back. My own mother would ask me, "how do I keep this from asking me these questions all the time?".
I know it doesn't have to work this way -- an installer can give an app a pre-set list of capabilities that one should be able to verify, log, change, audit, revoke, etc. Roles can be created out of capability groups to put some of the ease of ACL's back into the equation. But their their own example stories don't even make that clear. It's ivory tower, all about security theory without an ounce of human factors other than "the user will learn" and some laughable user education story about POLA.
The average server is reasonably secure right now, since it performs dedicated tasks and is administered by what one presumes are trusted people. It's the desktop that's providing fertile ground for attacks. Thousands of infected desktops hitting one server, and well, wouldn't it be nice if those desktops were secure? They won't be if security doesn't take the human factor into account.
I've finally had it: until slashdot gets article moderation, I am not coming back.