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."
This sounds like a serious one, I hope they fix it faster than Microsoft fixed their's
Ever heard of MacOSx.
----
Go canucks, habs, and sens!
...and isn't being able to run binaries unpriviledged a security hole, or am I just not getting it?
Anyone care to explain what this means and why it is significant? I know a little about BSD but this is giberish to me. TIA.
FoundNews.com - get paid to blog.,
...and isn't being able to run binaries unpriviledged a security hole, or am I just not getting it?
Yes
I know NOTHING about BSD, however I thought it was *nix-like and you didn't want apps running around all will-nilly ( yes I said will, nilly) with elevated rights. What makes this so news worty? Until I read the whole thing I actually thought a secutity flaw was unearthed.
What the fuck are you posting this for? Not only do you not understand the meaning of this feature, but it has nothing to do with Redhat or Linux.
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!"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.
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..
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?
They don't get it.
(snicker)
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.
Come to think of it, it doesn't mention Perl or Japanese animation either!
So how does this tie in with all the other security developments going on like the NSA stuff, for example?
some Bsd and Next OS. How much , i am not sure. Pure attempt to hijack interest in open source operating systems to sell his own proprietary os. Should have gone with BE operating system Steven.
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.
I'm not aware of exactly what NSA stuff you are speaking of. One thing to keep in mind is that OpenBSD is based out of Canada, not the USA. And to my knowledge there is no laws involving the exportation of crytography. Enabling OpenBSD to utilize this in the fixing of security issues. Comming from the project are other such gems as OpenSSH, which we all love and use, right?
So, unfortunatly with a generic question you get a generic answer of stuff that can be found on a half dozen links on their front page.
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?
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.
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
Couldn't the developers provide a list of syscalls
and argue why they need each. You could then
use it as your config file.
The developer could explain exactly why each call
is needed. Simple apps would just auto-generate the
list.
I knew BSD users were losing their sense of humor about the same pace as their hair, but there is nothing wrong with a bit of friendly on where to obtain an upgrade.
ACL's, MAC's and more http://www.trustedbsd.org/
I'm not aware of exactly what NSA stuff you are speaking of.
I suspect he's referring to SELinux, the NSA's "Security Enhanced Linux", which is basically a set of patches (libre) to add ACL support to a Linux kernel and a few select utilities. SELinux is basically just evidence that the NSA has its share of geeks excited by all this free/libre/open-source stuff too.
From the FAQ:
20. Are there any export controls on it?
There are no additional export controls for Security-enhanced Linux over any other version of Linux.
In answer to the original question, I think that the main difference is that SELinux is building the access controls into various syscalls, while this new OpenBSD feature is putting a wrapper around syscalls in general. The overall effect should be fairly similar, but there may be tradeoffs on either side. But don't quote me on that.
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.
Uh, no.
BeOS has some nice features, but it was also horribly broken in a number of ways, most notably security...
NeXTSTeP *WAS* BSD, btw. BSD with a nice GUI/desktop... just like MacOS X, in fact.
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.
This is the first real kernel-level security feature in OpenBSD.
Earlier versions of OpenBSD had only application-level security (secure applications, but running as root, and therefore no effective OS-level security below the application-level).
Granting certain privileges to an application instead of all-powerful superuser-privileges is IMO the most-important security feature of a secure operating system - this is a standard feature on every trusted unix system, and actually i believe it should be a standard feature on every unix platform.
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.
I'm wondering wouldn't all this work best with the Linux "sandbox" idea I believe it's know as UML?
Put all the dangerous stuff in the sandbox, and use this method to control the access points between the two? The fewer and tighter control will make it easier to audit for security. Also one doesn't have to go through the untrusted code with such a fine comb.
Well, actually, it looks like the guys at IBM are going that way. Not sticking the entire kernel on chip, but a bunch of helper functions ( I would imagine task swapping to be in there ) to assist the kernel, think of it as MMX for the kernel code. From the roadmap that was linked to from slashdot a few days ago, it looks like the kernel-accellerators are being built into the POWER5 series. Oh, and as for put string functions in the chip, it appears that is the next phase. In the POWER6 series they are planning on adding accellerator functions for DB2 and Websphere (I think a hardware accellerated DB2 is really gonna give Oracle a run for it's money). Just FYI
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.
It seems like a good idea, but since I am no Unix expert, could you please someone explain why, for example, accessing port 80 (web access) needs root access ?
Wouldn't this require more fine-grained syscalls in order to be effective? Without knowing how it actually works, I assume this system is dumb in the sense that it only allows certain syscalls to be executed throughout the program.
We all see how well going with BeOS worked out for Be. :)
Oh, wait just a moment, I believe the discussion as actually about privilege elevation, which is not a security hole, but rather a useful fine-grained access control for possibly dangerous system calls. My mistake.
Yours and 99% of the readership of Slashdot, it appears. I think this story has finally proven that the huge majority of the Slashdot readership is both clueless and stupid. I think I'll just carry on trolling.
Operating systems should not have any super user (root) account at all.
Why?
Those super priviledges are an anachronism which doesn't fit the world. Most of us live in a democratic society. Democracy has historical won over the hierarchical societies - for a reason. Now if we want to model the real world, we are orced to map it to a kingdom like world. If there was no super user to hack a lot of vulnerabilities where gone.
But we need administration! Yes, we need even more fine grained access control, but no entral authority. We need to grant and revoke rights and subrights among each other.
How? The Paper Askemos - a virtual settlement describes (among other aspects of Askemos) a set theory based priviledge system which handles that. (You might also look at the slides from the most recent talk at the netobjectdays.org conference here
(there only temporary).
The standard Unix security model, despite the 'courseness' of the method, is admirable for the ease with which one can set up a security policy, as well as audit the effects of an existing arrangement.
I would agree that some finer control over root privilege is probably worth the cost in complexity, and 'systrace' looks like one promising contender in providing a means of doing that.
In a free society you are who you say you are. -- Mumford
It's not ACLs. Think about it as some kind of evolution. First, there was the not-too-flexible Unix privilege system (users,groups, rwx bits). Then there were Access Control Lists. And the last step in the "evolution" is a role-based system with cool things like "there is no superuser". This is really a huge leap forward in the security of Linux.
:-)
(although, OpenBSD's system call sandboxing via systrace is still nifty!
A monkey is doing the real work for me.
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/
I just wonder, why so complicated ? Mandatory Access Controls, Priviledge Elevation ... some administrative nightmare. Probably more security holes by misconfiguration that bad code. Think sendmail.
...
Why do certain applications need to have root priviledges at all ?
Wouldn't it be more wise, to allow certain users to actually perform certain tasks. Fighting the cause but the symptom.
Like, defining e.g. via sysctl that user "named" is allowed to bind to port 52 on IP 1.2.3.4.
(You could still use capabilities to disallow sysctl.conf when in multiusermode)
That would be, only user "named" could bind, not even root to that ip/port.
So instead of "lifting" a binary to temporary root priviliedges with some black magic to allow some syscalls, why not telling the kernel that this user may do this and this
The difference is, you need no whatsoever "root faking". Don't let an application ever become root or needing rootpriviledges (when configured), no matter for how little time it may be.
Instead, be able to grant privileges to users at lowest level, insteat of cheating on the higher ones.
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.
Too bad OpenSSH has too many if ( uid == 0 ), and it won't work unless launched as root. .But I failed on doing so because OpenSSH refuses to work as a nonpriviledged user .
I tried to do a server with priviledge escaladation on linux, using RSBAC
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.
Actually it can cause big issues. Many crypto systems rely on knowing what the tme is, so that certificates can be ignored if they are out of date. So if you spend 5 years cracking a certificate, the certs are probably then out of date, but then you hack the ntpd server and suddenly they work again, and ssh succumbing is moments away.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Is someone porting this to FreeBSD?
Microsoft again is well ahead of the game!
It seems that all of their privileges can be escalated by anybody to any level desired. Now how can you beat that? (chortle)
Then I went to read the actual thing here, and I found that it also checks for syscall arguments, including some sort of pattern-matching (you can even change dinamically the system call arguments, making a sort of chroot-on-the-fly).
It looks like a promising idea. My only concerns are :
1 - performances
2 - setting up a policy file requires a good knowlwedge of system calls, and not many programmers (not to speak of users or sysadmins) have that. The interactive policy setup helps a little, but it is _you_ that have to say 'yes' or 'no'.
Ciao
----
FB
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.
... but it must be carried out well. I think that servers should be a combination of the old suid method and the new systrace. For example, If I run an apache server as user apache, and don't setuid in it, then if some one else finds an intrusion vector, let's say an openssl exploit, and then gets a shell as user=apache, he can then KILL the apache SERVER and all its threads. Then, the intruder can run her own server and bind it to port 80. Instead of running it this way, I think the apache server should be run as the old way, but setuid to a different user, apachea for example, then drop privilages for each of the client threads. This way, the intruder cannot kill the server (just the client threads... I've got some good code to do that) and cannot bind to 80 except in the httpd binary... So just because there's a new method for security doesn't mean that you shouldn't use the old as well.... Have fun hacking, ~DW~
Would/could it be a good idea to apply the acls to users or groups instead of binaries? As I see it it would make administration easier...!?
JC
1. Is this going to be in the new 3.2 release in November?
2. Do programs have to be re-written to take advantage of this feature?
The key word there is "integrates."
... FreeBSD". If Mac OS X were BSD, it wouldn't need to "integrate" anything.
Notice is doesn't say that Jaguar "is state-of-the-art FreeBSD". It says that it "integrates features from
NeXTSTEP was Mach with a BSD system call layer and pieces of a BSD userland.
Just because an OS has pieces of BSD doesn't mean it is BSD. If I coded a kernel module for Windows, with an 80h interrupt handler for BSD system calls, would that make it BSD? Because that's basically what Apple did for Mac OS X.
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.
I've often wished that *nix would add a third privilege level between the kernel and user-space. It would be ideal for trusted libraries.
As a specific example, think of libc. This library is always in memory and is used by almost every program. It would be trivial to have the kernel load it, plus a few other key libraries, into a special 'ring' between the kernel and user-space as part of the boot process. These libraries could be appended to the kernel image (e.g., via an embedded tar file).
User-space programs could call it as usual, but internally these libraries could never depend on user-space (instead of other trusted) libraries and could never be corrupted by user-space applications.
(Background: the Intel rings follow the standard protocol that a higher ring can call a lower ring, but can't modify data in it. Contrawise, a lower ring can modify the data in a higher ring but can't call it. Ring 3 is user space, and ring 0 is the kernel.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
And the failure to apply security policy using standard Unix facilities.
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."
What tosh!
So if you ever add to the code of anything, it ceases to be what it was?
FreeBSD's current kernel differs substantially from BSD4.4 - but it's still FreeBSD.
There's far more BSD than Mach code in Darwin - and NetBSD used to contain Mach code. So, by your standards, NetBSD isn't a BSD either?
And, of course, at one time Linux had BSD code in there too - but it was still Linux. And Linux is just the kernel, to boot.
Get real.
"If Mac OS X were BSD, it wouldn't need to "integrate" anything."
MacOS X isn't FreeBSD. MacOS X is BSD.
What weekly Linux kernels?? *BSD is no better than Linux for all intents and purposes.
Everything has its time and place -- and you'll note that Linux seems to be much more in demand, as well as having more momentum in most areas of development.
Well, you might want to start by changing "grammar, spelling, and style" to "grammar, spelling and style" to conform to the official AP article-writing style.
(I worked at a newspaper; there were posters everywhere reminding us not to add that comma.)
--grendel drago
Laws do not persuade just because they threaten. --Seneca
As I know, the idea was taken from Cerber kernel module developed for FreeBSD (started long time ago). Available at http://cerber.sourceforge.net/
-- mg
Just be careful with it! This is something a lab I worked at about 15 years ago did using rlogin. We gave a different password to each job. For example, "rlogin -l dcollector localhost" restarted one of the data collectors that had to run as root since it used a low port. The problem comes when you can use one of the tools as an exploit. For example, one of our lab equipment's data collection server programs would allow you to edit certain files by opening-up vi. Then using vi, you do the ":! /bin/sh" command, and you have a root shell. Another example, we had a user (who had just been fired) overwrite /etc/passwd by specifing that file as the output file for one of our root privileged commands ("SELECT ... FROM table WHERE ... INTO OUTFILE /etc/passwd"). Do you really trust all of the applications you're allowing the users to run? Neat idea, but it can be dangerous.z
For instance, Microsoft has had Privilege Elevation scince the beginning of networking!
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
You shouldn't have any extra code running on most system calls. System calls could run exactly as normal. The only time you have to do any extra checking is when a call would (otherwise) cause an exception.
The first thing that the exception code would have to do is see if there is a priv exception for that call (in which case it would be allowed). Otherwise you would get a normal error. Voila! all done.
Under this model, priv elevation would only cause a real performance hit if you did a huge number of 'dangerous' calls. The standard for most current SUID programs is to front load the dangerous stuff and then drop prives. In other words, most SUID program only have a couple (or a couple dozen) 'root' calls. Any programs that do more than that are likely be non-SUID (and need you to be root before you start them).
Apache, for example, might only need an elevation check when opening port 80 and (perhaps) the log files, not on (the more numerous) write/read calls. Similarly with X.
OS Software is like love: The best way to make it grow is to give it away.
Theo will have a cow.
Most certificates have expiry dates so that the issuing companies can make more money selling you a new one.
The flaw with this is that your named can still be subverted, and run any number of other syscalls, for things like reading files, creating files (albeit in places with 777 perms), binding other ports, exec a shell, fork some other app (a trojan that was uploaded to /tmp?), and so many other things.
/etc/localtime and write to certain network sockets (syslogd? nameserver queries/responses?). It can't write to /tmp, can't exec, can't fork, can't read other files in /home or /etc or elsewhere, or any of the sorts of potentially dangerous things that vulnerable apps have been known to do (the Apache/OpenSSL worm comes to mind).
You're talking about minimal uid privilege, which isn't really "minimal" at all.
systrace is about minimal syscall privilege - unless you as the sysadmin have explicitly allowed all of those things above, named can do nothing whatsoever. The policy would perhaps elevate privileges to bind to port 53/udp&tcp only on a single IP address, read configuration files from a certain path only, load certain shared libraries (libc is the obvious one), read
So what happens when someone finds an exploit for named, gaines access to your system as named, then decides to run their own version of the daemon? Why should their program be allowed to bind to that port?
I wasn't thinking about how nice *nix is at managing files... Just check the binary's last changed date. No need to parse through it to calculate the CRC on each execution.
This WOULD be easier for a hacker with root to spoof, but that wouldn't be its main purpose.
Imagine that, *BSD died. What would Linux and Windows do? Oh, and OpenBSD's OpenSSH that they ported to Linux and other OS's.
You can do this with systrace's priv esc code:
native-bind: sockaddr eq "inet-[1.2.3.4]:52" then permit as root
Besides which, Mach was itself an offshoot of BSD -- an attempt to rearchitect the monolithic BSD kernel as a set of user-mode servers running on top of a microkernel, with the BSD userland running on top of those servers.