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."

Comments

Serious!

[Trusty Penfold]

This sounds like a serious one, I hope they fix it faster than Microsoft fixed their's

Re:Serious!

[FordPrfct]

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.

Re:Serious!

[shird]

I think you misunderstood. The parent post is clearly a joke.

Re:Serious!

[FordPrfct]

Probably. Years of IT have blurred the lines between jokes and cluelessness in others.

IHBT. I will HAND.

2 things

[vga_init]

BSD is not dead! It's code lives on in every modern operating system today, most noteabley MacOS X. Go BSD! :)

...and isn't being able to run binaries unpriviledged a security hole, or am I just not getting it?

Re:2 things

[kamakazi]

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.

Re:2 things

[CoolVibe]

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,

One nitpick. Although you are correct, the phrasing is somwhat wrong. What you _mean_ to say is that dropping the privileges of the app is the responibility of the appication that's running suid itself. Now, that most apps can't tell if they are running suid or not, is not the operating systems responsibility.

But yes, you are correct though. Although many apps that must run as root (to bind a port below 1024 or something), usually prepare what they need to do as root (like open a socket and giving up a file descriptor that is bound to a lower port), and setuid() their way out of root land.

An extension like this should alleviate the need for such hackery. It's no excuse to write insecure code though ;)

Re:2 things

[CoolVibe]

Clarification: Now, that most apps can't tell if they are running suid or not, is not the operating systems responsibility.

What I mean by this is that lots of apps don't even test if they are running as root or with elevated privileges. This can simply be done by checking with getuid and geteuid and comparing them (although it's not a foolproof method).

Also, if an app tries something it shouldn't be allowed to do, it'll just get a EPERM and fail.

that's 3 things

[Anonymous Coward]

...and isn't being able to run binaries unpriviledged a security hole, or am I just not getting it?

Yes

Re:Explanation?

[roukounas]

Google is your friend, and the next link seems quite informative:

systrace

Re:Explanation?

[photon317]

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.

Doesn't any READ ?

[XTerm89D]

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 ?

Re:Doesn't any READ ?

[PotPieMan]

Same goes for X, which now no longer needs to be run SUID.

Does this mean X will run slightly slower compared with an suid installation? It seems like there would be more code running behind each syscall to check the configured policy, but it's probably not a significant amount - at least, not for current systems. I'm merely curious.

Re:Doesn't any READ ?

[Marillion]

Under the UID 0 approach, all calls needed to do something. I haven't peeked at the code, but if I were to solve the problem, I would frontload the overhead of the syscall policy evaluation to the exec() call, store the results in a bitmap field. From there, it's bit math. A if (priv & PRIV_SOMECALL) has no more overhead than if (uid==0)

Re:Doesn't any READ ?

[Cryptnotic]

Why not just make it SGID kmem (or mem or whatever group owns /dev/mem and/or /dev/kmem)?

It seems like that would be as easy a way of partitioning "root-like" permissions as any other.

Re:Doesn't any READ ?

[Saucepan]

Making the X server SGID kmem is still giving it far more privileges than it needs in order to be able to do its job. Just being able to read kernel memory is sufficient to get root in most cases (the easiest example to explain being reading the root password right out of the TTY buffers as root is logging on).

Hopefully the new feature makes it into other OSes -- Unix has long needed a standard way of doing this kind of fine grained privilege separation.

Re:Doesn't any READ ?

[lukew]

A little offtopic, but a great security approach that I haven't seen used to often is to port-forward port 80 to a non priviledged port Apache is running on (Say, 8080). Completely removes the need for root privs.

Re:Doesn't any READ ?

[Ed Avis]

If the X server does all its root-needing stuff at startup, then surely it can drop root priveleges immediately afterwards and so a suid-root X server is not such a security risk as often seems to be implied. Of course having no root priveleges at all and relying on a systrace policy is still a step up...

Re:Doesn't any READ ?

[FroMan]

This works for httpd fairly well. However, consider procmail. It needs to be able to write to any users mail file. So for certain servers it works well. For certain ones it does not. Others that might have problems would be crond also. If crond cannot switch to the proper user when executing it will not work either.

I don't see how this buys too much though. It doesn't explain the configuration policy. But I suppose if you can allow a certain app with the full path and maybe a checksum on the binary, then set the permissions to the app. like this: /usr/bin/procmail checksum +setuid() +setgid()

That might work. But it seems easier to just say you will allow procmail to run setuid root. It keeps the idea simpler and does not require that the administrator know exactly what syscalls procmail makes.

In summary, this might be a cool idea, but I think expecting a sysadmin to know exactly what syscalls an application needs to have for permissions is a bit much. Sure, you may claim that the admin should know these things, but do you really think an admin reads/understands all the source code that goes onto his system? I highly doubt it.

Re:Doesn't any READ ?

[lewp]

It's not a "need to know" thing. AFAIK they aren't planning on taking SUID/SGID out of OpenBSD or anything.

If you happen to know (or happen to be willing to find) the necessary syscalls you just get the advantage of a little better security. Even then, you don't have to do it if you don't want to.

Re:Doesn't any READ ?

[stripes]

Or you could store your own syscalls table for each process. At exec(), you init the table so that all syscalls are redirected to your handler, which then performs the overhead of checking the policy. If the syscall is allowed under the policy, then the process syscall map would be updated with the proper syscall information. Future calls to the same syscall would be passed immediately onto the kernel with no more overhead than your normal syscall mechanism.

Cool idea, and I know FreeBSD at least supports per-process syscall tables, that is how the Linux and BSD/OS "emulation" works. However having more syscall tables does have some real overhead, or could. When you do an indirect jump (table base address plus 4 times the syscall number is an indirect jump) if the jump can't be predicted you end up flushing the pipeline. Tieing that in with other slashdot articles that is 25 pipe stages times three instructions (max) for the P-III or 75 instructions worth of work or 6 cycles time 3 (or is it two?) instructions so 18 instructions for a PPC G4.

Having another table per process may make the branch prediction much harder since you'll have many more addresses for the branch target cache to hold. Er, maybe. It won't make a difference if the BTC has to be flushed when there is a process context changed (many CPUs have something like a PID that can be used for the different caches to reduce that kind of churn). Also if the CPU does the BTC based off of the physical address this may not be such a big deal (at least if an effort is used to share the tables).

Modern CPUs are a pain to optimize for.

Re:Doesn't any READ ?

[evilviper]

consider procmail. It needs to be able to write to any users mail file.
Okay... so you want to make those files owned by procmail's group so it can write to them, and only to them.

but I think expecting a sysadmin to know exactly what syscalls an application needs to have for permissions is a bit much.

Oh you poor /.ers... This idea is being thrown on you all at once, with the details hidden from you (i.e. on the systrace website).

Systrace has both a logging mode, and an interactive mode, in addition to the mode you've heard of already. So, you can run it in it's logging mode, and a week later go through the logs to see what calls it made, and use that to form your policy for that program. In the interactive mode, you get something like the Windows firewalls... The first time a program tries to make a call, you can permit it, deny it, deny it always, or permit it always. It's even got a GUI interface, so you could run all your programs that you don't quite trust (Mozilla, GAIM, etc) with systrace, and decide what you want it to be able to do, on-the-fly.

The moral of this story... the slashdot headline doesn't tell you everything there is to know... Next time, try and find out about the program in question before critizing it.

Re:Doesn't any READ ?

[evilviper]

Blah, blah, blah, overhead, security problems, complexity.

What we really need is Unix OSes to allow certain users to bind to certain privlidged ports. That would solve all the problems, and seriously reduce the need for something like systrace. I would say 90% of exploitable services only need root so they can bind with privlidged ports. Did I mention that 78% of statistics are made up on the spot?

Re:Doesn't any READ ?

[stripes]

Perhaps you were thinking of the P4?

I was, I even thought "P4" when I typed "P-III"!

Another point: you are oversimplifying when you say that we'd need to squash 3*25 instructions on a misprediction, it could be more, it could be less.

Yup, I'm oversimplifying wildly. There are also non-BTC effects I left out. However, what would cause more then 3*25 instructions to be thrown away? Things living in the register rename buffers? If so how many? If there a separate re-order buffer later in the pipe, or is that done with the register rename ones?

Re:Doesn't any READ ?

[cant_get_a_good_nick]

Apache kind of already does this. Though the main (possibly root) apache does do the listen/accept, it doesn't do any reads of the data, it passed the open fd down to the child which then does the processing. root can't get hit by any buffer overflows, nothing is put into any buffers to overflow them. If you look at all the buffer overflow info for apache bugs, you'll see they pretty much say "Allows intruder to interact as apache user" not root, this is why.

Of course, this is true in 1.3 and the PREFORK_MPM of apache 2.0. Not sure if the other modules have a "root parent" and then pass it off to a lower privileged client.

Sounds like a (very) good thing

[WolfWithoutAClause]

I've always hated the all or nothing priviledges that Unix uses.

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.

Re:Sounds like a (very) good thing

[jhouserizer]

Actually, this type of security is pervasive throughout the _standard_ Java libraries ... not just tied to netscape or any other implementation.

Java's one of the few programming languages that has security built in from the ground up.

And yes, this new BSD feature is VERY similar to Java's declaritive security mechanisms.

(Please let's not start a war of "Java is cool vs. Java sucks", I wanted to provide the above!)

Re:Sounds like a (very) good thing

[Zeinfeld]

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?

Java was the first programming language to claim that security had been built in from the ground up. In practice the first versions of Java were not at all secure with lots of holes and a security architecture that was pretty clunky. Every call had a wrapper to check the privs separately, there was no security monitor concept, a single point of auditability.

dotNET does have a strong security monitor concept and a very comprehensive security model. For details see Brian LaMacchia et al. ".NET Framework Security". And yes that is the same Brian who is talking on palladium in LCS today.

I don't quite get what you mean by stating it would be good if IE only acceted dotNET attachments. Certainly it would be good if Outlook was written as dotNET managed code, or at least the attachment handling was. Then attachments could be run in restricted priv mode.

The BSD hack appears to be much less sophisticated than Java or dotNET. It is really just adding back something that most security specialists have thought UNIX lacked all along, granular privilleges. The SUID hack has always been a kludge.

Interesting, but ...

[yeOldeSkeptic]

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.

Re:Interesting, but ...

[alannon]

chroot jails are almost completely unrelated to system-call security, unless the system call is to the file-system. chroot simply allows you to change the root of the file system so that the application cannot access part of the file-system beneath it. If the process is running as root, this helps nothing, since there are many ways of accessing the complete file-system bypassing the normal means if you are root.

Re:Interesting, but ...

[Soko]

Yes, chroot jails are effective, but there are times when data - possibly sensitive data - has to be kept within the jail, or the daemon needs access to something outside the jail. Chrooting a secure HTTP server that is then compromised by a buffer overflow for example, would expose the files and databases that the HTTP daemon has access to. That is more easily a "get-out-of-jail-free" card than locking down single APIs.

I would put forth that granting setuid via this method is more effective at securing systems, since you can more easily make sure that the API calls that need privs are written well and bullet proof. Minimal exposure to security risks is what we're after, right? So, this minimises the time that apps can expose themselves to major compromises, even more than a chroot jail. Both together means even better security.

BTW, ACLs aren't much of a strain if done well - look at NTFS 5.1, which IMHO has ACLs done very well indeed.

Soko

Re:Interesting, but ...

[jolan]

Setuid / setgid requires the program to do all it's privileged dirty work initially and then drop privileges to ensure a reasonable level of security.

This new feature in systrace reverses the whole process. Now daemons can run totally unprivileged and systrace can escalate privileges as needed for only the calls that need it.

It's not as taxing as you think it is. Yes, there is slow down, but for the huge blanket of security it adds, I think the hit in speed is offset by the benefits.

Chroot jails for each application isn't necessarily feasible. Take Apache for example.

Apache in OpenBSD 3.2 runs in a chroot jail and even the parent process is run as www:www.
Some of the apache modules in OpenBSD ports were modified to be chroot-aware. Some are hopeless.

Properly configured Systrace policies can make the aforementioned broken modules work again and reduces the need for chroot.

Re:Interesting, but ...

[Fweeky]

Blegh, will people please stop using "chroot jail" when they really just mean "chroot"?

This is jail - a syscall which puts a process inside it's own process list, user list, IP and root directory, while limiting various syscalls which might make it possible (or at least easy) to escape the jail.

This is chroot - a syscall which puts a process inside it's own root directory. As you said, this is almost completely unrelated to system-call security.

chroot is not jail, jail is not (merely) chroot. Calling chroot "chroot jail" actually makes it *less* clear what you're talking about.

Re:Interesting, but ...

[Fweeky]

Can't you configure applications to run both in chroot and jail to more fully contain them?

Sure, if your chroot has jail set up inside it. It's unnecessary, though; jail already implies chroot, and if you can break out of the jail, the original chroot won't help much :)

The BSD network stack virtualization experiment may also be of interest, btw. It goes even further than jail :)

Re:Interesting, but ...

[scrytch]

chroot(2) has been called a "jail" for longer than the jail(2) call has been around. jail(2) just generalizes the concept (though I'm not a fan of how they bound it to network interfaces instead of some other declared entity like a mount point or even a pseudo-device)

Go OpenBSD!

[snorggle]

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..

Re:Go OpenBSD!

[lbruno]

I run this fun little operating system on a produciton machine. 20 days away from one year uptime

PLEASE UPDATE YOUR SYSTEM, DAMMIT!

Re:Article is over most /.er's heads

[dmanny]

I believe the comment to which you replied is fairly well on target but it is not very polite. The development is a significant benefit but I agree with you that everyone who uses a machine for the desktop does not need to be understand this subject. There are almost always many, many things that individual users do not understand about the complex systems they use. That doesn't mean that significant discusion between those that are interested in a particular area is without value.

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.

You answer your own question...

[Carnage4Life]

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.

Re:You answer your own question...

[yeOldeSkeptic]

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.

setuid and setgid are not perfect and the recent spate of Linux vulnerabilities certainly speaks of the need for improvements in this area. My point is that doing away with setuid and setgid and replacing it with per system call access privileges does not seem to be the right way to increase security.

With Posix (and Linux, which is Posix compliant) it is already possible for an application to drop it's privileges. This solves the problem of an application running its entire life as root. With the posix compliant call to setuid, an application can be setuid root only for as long as it needs to access privileged resources and can drop those privileges once it no longer needs to be root.

However, the above article talks about an application elevating its privileges and for the kernel to grant that privilege on a system call basis. The article is short on the details but elevating the privileges of an application is certainly a very dangerous process. If an application asks the kernel to elevate its privileges, how is the kernel to decide if it should grant that request? My mind-set tells me that it should check the effective user id of the running process but then isn't this setuid and setgid again? If the kernel will grant this request by checking a list of applications that is allowed to do this, then how is this different from a kernel checking if an application is owned by root?

I have stated my preferences for chroot jails and for a good reason. Once a system is cracked, the intruder can do with the filesystem as much as he pleases. At least with chroot jails, the intruder is restricted to the chroot directory and cleaning up the mess is easier. Yes, I know this is not a cure but I think the idea of jailing applications to a particular environment is a good idea.

I am an old hand so my mind has petrified with an imprint of the old ways of doing things. I could be wrong, but until I am fully convinced, I will be among the voices that express caution at the idea of throwing away setuid and setgid.

Just my half cent.

Re:You answer your own question...

[Nickus]

There is no need to speculate in how it works when you can just go to the webpage and have a look yourself. http://www.citi.umich.edu/u/provos/systrace/

Re:You answer your own question...

[Carnage4Life]

You are working backwards. Looking at it objectively, it is clear that a system where applications have to become superuser to perform certain tasks but can relinquish this authority is inferior to a system where superuser priveleges are never given to a process.

Your position is understandable since this is how the Unix security model has worked for decades even though better mechanisms have been proposed but rarely caught on. For example, look at POSIX 1.E which is almost 2 decades for an example of a better model for handling systems permissions than the traditional Unix model. Recently there has been work done on FreeBSD POSIX 1.E capabilities as well as on the Linux front. This is a good indication that more and more people are disatisfied with the deficiencies of the Unix security model and its reliance on a "superuser" account for so many essential tasks.

Lastly I don't think any Linux distro has ever been certified as POSIX compliant although many feel that doing so wouldn't be difficult.

Re:You answer your own question...

[RAMMS EIN]

``With the posix compliant call to setuid, an application can be setuid root only for as long as it needs to access privileged resources and can drop those privileges once it no longer needs to be root.''
This means that the application is allowed to execute any code as root, as long as it does setuid(0) first. Easy enough to sneak some malicious code in...

``If the kernel will grant this request by checking a list of applications that is allowed to do this, then how is this different from a kernel checking if an application is owned by root?''
It's _very_ different. What this new system does is selectively allowing _some_ system calls that have traditionally required root priviliges to be executed by less priviliged users. For example, a webserver is allowed to bind to port 80, and X is allowed access to graphics hardware (note that svgalib has an IMHO elegant solution for this using kernel modules). Neither the webserver nor X need root access to the filesystem, so they aren't granted this under the new scheme. With setuid, there is no choice - granting access to ports 1023 requires root privileges, which can also be used to read and modify any file on the system.

setuid is flawed and needed revision. If OpenBSD gets it right remains to be seen, but it's good they're trying. And since the OpenBSD dev team and its users consists in large part of hard-core security freaks, I have faitht that this is going to be a win. Congratulations on yet another great innovation from the OpenBSD folks!

---
After months of research, they found the solution. Typewriters. They are intuitive to use, free of security issues, not hampered by unstable software, and you never have to wait for the printing queue again.

This is a good thing?

[LordOfYourPants]

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?

Re:This is a good thing?

[perry]

What you're saying is "if the mechanism itself has a horrible bug might that let you break security?" Well, of course.

However, if there is some sequence of syscalls that lets you, say, get root, well, you have root, and the game is over. What systrace means is, if you have a system with a reasonably bug free set of system calls, you can reduce or eliminate the vulnerability that misbehaving root privileged programs might cause.

As an example, is really far better for, say, your ntpd to only have the ability to run the normally root prived ntp_adjtime call rather than to be able to do anything root could do. Systrace also lets you give up the ability to run calls like fork and exec that a given program may not need (ntpd does not need them). That way, if someone remotely breaks ntpd, well, they don't own your machine -- at best they can crash your ntpd. They can't fork a new program (a typical exploit would fork a privileged /bin/sh), and they have no access to "normal" root prived calls.

Re:This is a good thing?

[evilviper]

That way, if someone remotely breaks ntpd, well, they don't own your machine -- at best they can crash your ntpd.

A big bad hacker broke into my OpenBSD box and changed the time... THE HEARTLESS BASTARD!

Re:This is a good thing?

[Ben Hutchings]

This could cause a serious denial-of-service by breaking distributed authentication requiring synchronised clocks, or it could cause information leakage by triggering at-jobs scheduled for the future whose existence would not otherwise be known.

Logo!

[snorggle]

What?!? No blowfish logo? Not that the little devil doesn't work or anything, but I'm used to seeing the blowfish associated with OpenBSD.

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.

Re:Explanation?

[cpeterso]

Isn't this "Privilege Elevation" really just an implementation of capabilities? Given the proper capability token, the program can now access a particular priveleged resource (eg syscall).

I've read a little about Linux's supposed support for capabilities, but I haven't read about any program that uses it..?

Re:Explanation?

[pnatural]

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.

A sample apache policy is here: http://www.citi.umich.edu/u/provos/systrace/usr_sb in_httpd.

Re:Why is this a good thing?

[coene]

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!

Only system calls?

[Virtex]

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.

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 /etc/priv.conf can only be read by root). An attacker could execute a

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.

Re:Only system calls?

[BlueUnderwear]

<sarcasm>
Or, we could make processors with more levels of priviliges. Ah, hell, put the string functions in the chip. Screw that, let's put the kernel in a chip.
</sarcasm>

Don't laught: the common Intel processor does indeed have four levels of privilege (even though most OS actually only use two of them...). And yes, it does have special opcodes for strings (REP MOVB) too. Only thing that is still missing seems to be the kernel integrated on a chip... Ah, the beauty of CISC.

Re:Only system calls?

[bastard42]

I think that's what I'm talking about. I was trying to make a joke about how these things were already tried w/ transistors. Maybe it is time to reexamine that thinking. (Or not.)

Thanks,
cts

P.S.
Ya, I know, but when REP MOVSB was cool, so was 64k (Ok, it lasted through the 286, but you know what I mean.) And why don't we use the >2 levels of privilege? (I don't know, but it's probably on lkml. Are the other ports better w/ this?)

P.P.S
wouldn't "mov ip,Word Processor" be cool!!!!

Re:Only system calls?

[MobyDisk]

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?

Is there a good reference for how libraries are loaded (other than the man pages to ld)

As another note, Windows has had the ability you describe since win32. Most calls take a SECURITY_DESCRIPTOR pointer that is usually NULL, but can be used to elevate priveledges of a function call.

Re:Only system calls?

[maraist]

And yes, it does have special opcodes for strings (REP MOVB) too.

I'm relatively sure but these op-codes are somewhat inefficient from the Pentium on; they're recoded via micro-code. While it's possible to still optimize (via utilizing closer-to-metal assembly language), this generally falls into the category of vectored complex and slow code which benchmarks rarely consider. Further, any such optimized complexities could slow down the otherwise streamlined micro-code.

That being said, it's probably possible to achieve code-size gains (through cache conservation) due to the 8086 sized instructions. However, even this probably doesn't generally apply because both the Athlon's and the P4's try to store the assembly language decoded in pseudo-micro-code form in their lowest level caches. Therefore a required 4 -> 16 micro-ops might be larger than a gcc RISC compile version of the same string operation. (Note, read RISC as meaning non-specialized CISC instructions)

Re:Only system calls?

[scrytch]

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...

Re:Only system calls?

[Virtex]

But fopen isn't a system call. It's a ANSI library function that wraps the real system call (in the case of Unix, open). What I'm getting at is that by using LD_PRELOAD, you can write your own fopen and have it execute in place of the one in libc. Then you can make it do whatever you want, including creating a root shell.

Now in the case of OpenBSD's idea, you're right. Since only system calls can get elevated privileges, this kind of attack won't work. That's why I like their idea.

Re:Only system calls?

[cant_get_a_good_nick]

We'll say this function is set to run as a setuid root (maybe /etc/priv.conf can only be read by root). An attacker could execute a

export LD_PRELOAD=/home/attacker/libc.so

This is a problem now, depending on how a setuid/setgid program takes their privileges. So the runtime linker can:
ignore LD_PRELOAD (a lot of systems did this before) or libraries from "trusted" locations can be used.

Re:Explanation?

[tumbaumba]

I see it to be a *good thing* indeed but does not solve all the problems and the most important running login daemons like sshd which eventually has to change to a different user and thus has be run as a root to call setuid(), on the other hand if rules allow to elevate privileges for setuid() then it is sort of meaningless. What we need is to have a possibility to change user without compromising security. Any ideas?

This is very very good.

[Ulmo]

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.

Question -- what if Apache code changes?

[A nonymous Coward]

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?

Re:Question -- what if Apache code changes?

[TheSHAD0W]

Very good point; and a new feature might require a new privilege setting, which would cause errors until the policy was redone.

The policy also doesn't protect against exploits which use privileges that were already authorized, though it's still an improvement over SUID/SGID.

It would be nice to add a CRC-32 to the policy file, and check the CRC each time the code is run. If a difference is discovered, indicating either a hacked executable or an upgrade, a warning could be given that the policy might need to be changed.

Re:Question -- what if Apache code changes?

[bockman]

This method needs to be supported by packagers: when you upgrade a packet (binary or source) for a system that supports this method, the package should contain a new policy file.

Ok, this lead to the question: what if the policy file is compromised? Even so, spotting an unneeded privilege in the policy file should be easier than spotting some rogue code in a large program.

Re:Question -- what if Apache code changes?

[TheSHAD0W]

That may be true security-wise, but the CRC check would still add some convenience.

Re:Question -- what if Apache code changes?

[nightfire-unique]

It might be a good idea (if this becomes standard across platforms) for daemon writers to include a standard policy file with their source/binaries (you're trusting their code anyway :).

That way, upon installation, you have the best rule set you're likely to ever have, for that application.

Finer-grained privs. Linux 2.5 has them too. +/-.

[dwheeler]

First, an explanation for those who wonder what this means: this addition is a method for gaining finer control over exactly what privileges a trusted program has. If the method is actually used by the system, the system could be more resistant to attack. That's because even if an attacker took control over a privileged (trusted) program, the privileges of that program would be more limited.

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.

Er, this was added to NetBSD first

[perry]

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?

Re:Explanation?

[gehirntot]

That is a good remark.

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.

...Except it didn't appear in OpenBSD first.

[perry]

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.

Re:...Except it didn't appear in OpenBSD first.

[Geekboy(Wizard)]

Niels Provos was originaly an OpenBSD developer, and started the priv-elevation code on OpenBSD. He hasn't commited to OpenBSD in several months (current theory: fight with Theo). He commited the code to NetBSD, and Itojun commitied it to OpenBSD something like 2 days later.

Niels also wrote systrace for OpenBSD, and ported it to NetBSD.

You are right, he is a great security guy.

Moderation?

[VTg33k]

"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.

Re:Explanation?

[BrookHarty]

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.

Appeared in NetBSD first

[jolan]

Niels Provos was an OpenBSD developer until recently. He's the same guy who did the PrivSep code for OpenSSH.

It actually appeared in NetBSD first.

http://mail-index.netbsd.org/current-users/2002/ 10 /11/0039.html

Re:Explanation?

[gehirntot]

Isn't this "Privilege Elevation" really just an implementation of capabilities? Given the proper capability token, the program can now access a particular priveleged resource (eg syscall).
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.

Re:Why is this a good thing?

[tpv]

OpenBSD takes the next step ... Only they have the bravery...

Except this change originated in NetBSD.

ACL's, MAC's and more

[fbsderr0r]

ACL's, MAC's and more http://www.trustedbsd.org/

Re:Go OpenBSD!-Frame of reference.

[Xtifr]

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.

Re:Sorry but MacOSX is based on Mach kernel and so

[Anderlan]

Huh?

http://www.apple.com/macosx/jaguar/unix.html
... Jaguar integrates features from state-of-the-art FreeBSD 4.4...

What is the policy?

[njchick]

Sorry for stupid question, but I cannot find any explanation of how the policy is configured. What should the program do to authenticate with the kernel and get the permissions defined in the policy?

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.

Re:What is the policy?

[perry]

The method employed is somewhat fiendish. A systraced program is "mastered" by a systrace daemon that gets information on all its system call activities and either thumbs up or thumbs down particular requests. (For performance reasons, things get fast pathed in many instances so the upcall doesn't have to happen.)

Because of the way that this works, via a userland policy engine, the systrace daemon (which is user code) can use any method it likes to determine how to implement the policy. The way it is currently implemented, the systrace program reads a policy file associated with particular programs and makes decisions that way.

There is no need for a program to authenticate to the kernel because the program itself has no knowledge of the policy and cannot evade it in any reasonable way.

The mechanisms involved are still evolving a bit, but Niels has come up with a bunch of really good tricks here. I don't know that systrace is a finished mechanism as much as a toolkit for building new and more interesting mechanisms that are in the tradition of ACLs but much more flexible.

Re:What is the policy?

[rweir]

IIRC, you run the program through once, and the kernel stores all the priveleged calls in the policy file. This defines the set of allowed operations. During subsequent runs, the kernel checks this file to see if each priveleged operation is allowed.

Re:What is the policy?

[Permission Denied]

The way it is currently implemented, the systrace program reads a policy file associated with particular programs and makes decisions that way.

Stupid question: how does this work? How do you figure out what program is running? Are you checking device + inode? Simple string comparison on filenames may not work correctly with chroot. Device + inode may not work correctly with hard links.

Just curious.

Re:Article is over most /.er's heads

[Anonymous Coward]

This article is clearly over most slashdot readers' heads.

Huh? I don't get it.

Except....

[perry]

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.

Re:Why is this a good thing?

[njchick]

There are measures in the kernel and in libc that restrict potentially harmful influence on the suid binaries, even from the user who runs them. Those programs don't get some signals from the user, they ignore most of the environment, and they are usually not writable by the user unless the sysadmin is an idiot.

When running a suid program, you know what you are running. Except there are serious bugs in the code, the program will drop its privileges or exit.

Now, with security elevation, somebody starts something, and that something says to the kernel - hey, I'm Apache, I want to write to the Apache logs. And then it fills the logs with some garbage. Unless there is a serious mechanism in place to authenticate the binary, I don't see how this is safer that running software designed to work safely when it's suid.

Real security

[octogen]

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.

Re:Why is this a good thing?

[perry]

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.

false sense of security

[g4dget]

UNIX has evolved for nearly 30 years around the idea that processes either have root privileges or they have user privileges. It's a sound and simple system. If, against that background, you add support for giving processes individual privileges, you risk doing more harm than good. 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. So, if you give a process specific privileges, you risk that it can acquire more because other processes will give it more trust than it deserves.

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.

Re:false sense of security

[perry]

Your comment is rather vague. Let me be more specific.

Lets say that you have an smtp daemon. With systrace, I can very easily elevate it to be able to open port 25 on the system, and restrict it so that it can't fork or exec any programs and can do no i/o other than writing to files in /var/mail.

Sure, you can theorize about how evil and complicated this is, but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon -- and in most cases I don't even need to have the daemon be the least bit aware of how systrace works. Once I've done this, I can't make the smtp daemon fork a /bin/sh for me, I can't make it write to random files on the system, indeed, I can barely write a remote exploit for it at all. Add in a little chroot and other magic and suddenly you have a very hardened program.

Most of your comment seems to consist of platitudes about simplicity, not any actual experience with using systrace in a practical system. It very much adds security to the way systems run, and it is completely in the spirit of most modern security aware code, like the Postfix mailer or privilege seperated ssh.

Re:false sense of security

[g4dget]

Lets say that you have an smtp daemon. With systrace, I can very easily elevate it to be able to open port 25 on the system, and restrict it so that it can't fork or exec any programs and can do no i/o other than writing to files in /var/mail.

First of all, your logic is invalid. If there exist cases in which the consequences of elevating specific privileges are easy to understand, that does not mean that the consequences of elevating specific privileges are easy to understand in most cases.

but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon

Even though you hand-picked SMTP as an example to illustrate your argument, it even breaks down there. If I can acquire this privilege set you think of as so restrictive, for example by compromising the SMTP daemon, all of a sudden, I can intercept any mail message and deliver it to myself. That is very likely enough to break into someone's account because either passwords or information useful for social engineering get sent through the mail system.

On the other hand, if the SMTP daemon runs as root, the threat analysis for a user of it is much simplified. If the SMTP daemon is already compromised and runs as root, it doesn't matter whether I send information through it that might give an attacker root privileges on this machine.

Most of your comment seems to consist of platitudes about simplicity,

Most of your comments are platitudes that show little actual experience in how systems are skillfully broken into. Beyond script kiddies exploring spectacularly gaping holes in poorly written C programs that just give them root shells, systems are compromised carefully and incrementally, exploring one subtle flaw after another.

Re:false sense of security

[g4dget]

However, then we'd have to say that Windows 98 is better than unix, because there is no security at all,

When I need a car to get me from point A to point B, a ham sandwich won't do. But among cars, I still prefer the ones that are safer.

Yes, they try, and they fail frequently, that's why we have buffer overflows in applications

And those buffer overflows won't go away through a complicated system of privileges. We need to get rid of the buffer overflows themselves, not make imperfect attempts to mask them.

Re:false sense of security

[Jouster]

but the truth is in one fell swoop I've made it fiendishly difficult to exploit the smtp daemon

Even though you hand-picked SMTP as an example to illustrate your argument, it even breaks down there. If I can acquire this privilege set you think of as so restrictive, for example by compromising the SMTP daemon, all of a sudden, I can intercept any mail message and deliver it to myself. That is very likely enough to break into someone's account because either passwords or information useful for social engineering get sent through the mail system.

On the other hand, if the SMTP daemon runs as root, the threat analysis for a user of it is much simplified. If the SMTP daemon is already compromised and runs as root, it doesn't matter whether I send information through it that might give an attacker root privileges on this machine.

You've got to be kidding me.

Are you honestly suggesting that it is worse to expose a small portion of the system than to expose the whole system in one monolithic chunk, simply because it would make it harder for you to write threat analysis reports?

Anything a malicious user could do under a privilege elevation system could be done "better" (so to speak), faster and easier under a setuid system.

Most of your comments are platitudes that show little actual experience in how systems are skillfully broken into. Beyond script kiddies exploring spectacularly gaping holes in poorly written C programs that just give them root shells, systems are compromised carefully and incrementally, exploring one subtle flaw after another.

Two things:

1. Most malicious users are script kiddies. Learn to deal, modify your security policy accordingly, and you'll eliminate 99.9% of security-related incidents. If a real hacker wants in, on the other hand, your only hope is closely watching logs and hoping you're good enough to notice the subtle signs of an elite's exploit.
2. Having broken into my fair share of systems and analysed dozens more intrusions, I can say that most non-script-kiddie exploits occur in one or two steps, the traces of each of which are covered by the triggering of the next. A hacker once abused an incorrect MySQL installation to put an exploit in place that waited for someone to "su - " into a tape backup account. It sent out a single UDP packet (yes, UDP, and no, he didn't check for loss--the second mistake he made) to let him know the system had been compromised. The first mistake he made was a mispelled "rm" (he put "rn") when trying to cover his tracks, which showed up on the screen of our backup user and caused a call to my office. Later, when playing with the executable--which, by looking at backups, we dated as being from six months previous--I triggered its UDP send, just to see what would happen. Within seconds, a flurry of UDP datagrams occured, and I was flooded with a hundred UDP requests to ports over 32768. The UDP packets synced a random number generator seed that was used to determine the ports the exploit would listen on. The instant it received a datagram on a port, it would close that port and listen on the next one. Thus, to our very sensitive IDS, what would otherwise have shown up as an elevated level of activity showed up as a relatively harmless port scan, albeit odd insofar as it used UDP. The data sent was in the form of DNS queries, with the hostname containing sixteen nibbles of hex followed by ".google.com"--no responses were sent. The hundredth port was reserved for communicating a new random seed for port numbers. From looking at the data that was sent, it appeared he was auto-updating the executable to the latest version. In my summary of the incident, I noted that, if we ever found this guy, I wanted to hire him and all his friends.

Conclusion: Yes, incremental, subtle attacks are much harder to detect and prevent than other attacks, but I've investigated three dozen or so "real" attacks, and probably half a million port scans and script kiddies running the latest 'sploit from BugTraq against a Class A at a time. Your guess as to who I spend most of my time fighting.

Jouster

Re:false sense of security

[g4dget]

Are you honestly suggesting that it is worse to expose a small portion of the system than to expose the whole system in one monolithic chunk,

I'm saying that the way to deal with security problems is to fix the software in question, not to make the problem even more complex with yet another software layer.

simply because it would make it harder for you to write threat analysis reports?

Understanding threats isn't some tedious exercise in satisfying management, it's something you have to do in order to be able to write secure software.

Your guess as to who I spend most of my time fighting.

And that won't change until people who write software (1) make an effort to understand security and threats and (2) address security problems by fixing the root cause rather than adding even more complex softawre into the mix.

URLs would help

[Anonymous Coward]

The URL describing this stuff is

http://www.citi.umich.edu/u/provos/systrace/

Using ssh to rid oneself of suid/sgid

[OoSync]

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

Re:Using ssh to rid oneself of suid/sgid

[Zigg]

All good and well (and I use it at work to perform tasks as the Oracle user, especially those that have X clients), but it doesn't solve the problem that you still have to give root access to certain programs to perform certain functions. There are set[ug]id-specific attacks this can mitigate, but quite frankly, you're not gaining much if your target program is insecurely written.

Re:Why is this a good thing?

[Random Walk]

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.

like that (overwriting will not change the inode) ?:
cp apache apache.tmp
cat rogue_executable > apache

please someone explain

[master_p]

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 ?

Re:please someone explain

[Observer]

... why, for example, accessing port 80 (web access) needs root access ?

Basically, because ports used for 'well-known' services, like port 80, shouldn't be readily available to arbitary programs, because that would allow a mischievously constructed program to bind to such a port and start serving inapproriate results (or, indeed, just do nothing). The standard IP stack implementations reserve port numbers under 1000 for these well-known services, and typically require that a process attempting to bind to them has some sort of (OS-dependent) privilege. Unfortunately, under classic Unix, 'privileged' equates to root access - it's an all or nothing thing.

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.)

Re:please someone explain

[Zigg]

The standard IP stack implementations reserve port numbers under 1000 for these well-known services...

In the interests of pedantry, it's actually ports below 1024.

Re:please someone explain

[rweir]

The standard IP stack implementations reserve port numbers under 1000 for these well-known services

Uh, 1024, of course. 2^10, after all.

Re:please someone explain

[listen]

And this whole "privileged ports" concept was created back when the evil-doers were local users. Nowadays it adds very little security, given that any evildoer will have thier own machine. Even back in the day, it was a kind of broken concept.

The things it prevents are eg someone managing to crash httpd, and start a new one from any old user. I think it caused a whole lot of more serious problems.

In my opinion, the best way to do this was the Plan 9 approach, IIRC, a special filesystem - eg /tcp/bind// for binding, ( meaning you can set permissions for individual ports).

The new feature is nice, but it does seem a tad heavyweight for some uses.

what is root good for at all?

[duplicatedAccount]

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).

Re:what is root good for at all?

[Corporate Troll]

Well, you might be right.. This only works on big systems where you *can* distribute different privileges over different persons This won't work for the single IT guy that has to manage the network of a small bussiness.
Also consider this: who decides whom should get granted what rights? Well, that person is automatically superuser, because he simply can give himself all the rights without telling anybody. The problem with a System Administrator is simply that it should be a "person of trust", if you don't trust him, you should get rid of him. It's that simple.

I can only say: I like being a tyrant on my systems. But I'm a fair and good tyrant for I respect my users and don't go and meddle with their data.

You can have my root account if you pry if from my cold dead hands.

Re:Article is over most /.er's heads

[spakka]

50% of the comments are asking what this means, and the other 45% are asking if this is a security flaw.

and the other 5% can't even add up.

EROS: The Extremely Reliable Operating System

[Anonymous Coward]

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/

That'll ensure the need of trained sysadmins again

[Anonymous Coward]

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.

Democratic/Autocratic rule

[nuggz]

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.

Assumptions

[nuggz]

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.

Re:Assumptions

[g4dget]

Assumptions cause trouble

If you are saying that all assumptions cause trouble, that's logically absurd. Or do you write your code assuming that assumptions cause trouble? Well, then you better stop right now making that assumption.

What it comes down to is that some assumptions lead to less security, other assumptions lead to more security. In particular, writing your program as if it were run as root--"assuming the worst case"--makes it more secure. On the other hand, writing your program assuming that something like systrace will protect the system even if your program has bugs will lead to less security overall. That's my point, and it seems that, except some confusion around the term "assumption", you actually agree with me.

ntpd is critical Re:This is a good thing?

[WolfWithoutAClause]

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.

Re:ntpd is critical Re:This is a good thing?

[evilviper]

but then you hack the ntpd server and suddenly they work again, and ssh succumbing is moments away.

I might believe that if I had no clue how SSH worked... Indeed, there are many other methods used to prevent replay attacks. If there were not... then replaying an SSH packet immediately after the original, would work. AFAIK, SSH doesn't even need clock sync between server and client. It does not use the clock at all.

Kerberos requires the time to be close to syncronized to allow authentication... but again, a clock that has been adjusted will not suddenly allow a replay attack.

Perhaps months later, you've been able to decrypt the encrypted packet, but so what? If you've decrypted the password, you aren't in need of changing the clocks to use it, and the password has likely been changed already anyhow.

Perhaps you'd like to enlighten me as to some method you've got in mind, where changing the clocks can result in anything more than a possible DoS... I know many common network encryption systems quite well, and I can't think of anything very significant.

Re:ntpd is critical Re:This is a good thing?

[WolfWithoutAClause]

Perhaps months later, you've been able to decrypt the encrypted packet, but so what? If you've decrypted the password, you aren't in need of changing the clocks to use it, and the password has likely been changed already anyhow.

No it's an attack on certificates. Most certificates have an expiry date, because you think they could have been cracked. Once they have expired, if you have cracked a (presumably relatively short) public key and retrieved the private key you can misrepresent yourself but only if the time reference can be subverted, since the certificate will probably have expired by the time you've managed to do this.

As you noted, Kerberos also has had issues in the past.

Secure systems really need cryptographically signed time references.

Re:ntpd is critical Re:This is a good thing?

[evilviper]

mindstrm has it right... There are mechanisms such as certificate revocation lists in case one is mis-issued, or stolen.

if you have cracked a [...] public key and retrieved the private key you can misrepresent yourself but only if the time reference can be subverted

Well, hell... If you have the capability of finding private keys frome the public key, just get verisign's public key, then you can go about finding their private key. So instead of breaking one key for one site... you can break one key, and generate your own certs for any site.

It allosw for arguments checks, also

[bockman]

I had the same thought ('if it only checks the access to the system calls, how can I prevent/grant the access to single files/directories/port numbers?).
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'.

Further complicating the *nix security system

[Peaker]

Will never make it as close to the principle of least privelege as capability systems such as EROS, or KeyKOS. (And no, by "capabilities" I mean EROS-like capabilities, not the POSIX re-definition of the word "capability").

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.

Re:Further complicating the *nix security system

[octogen]

There are still a lot of problems with capabilities.

* Simple security paradigm with a single simple-logic security test per request.
What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.

The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).
But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.

No global namespace
Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on ..

The catch is that user A has no way to know what other programs are running on behalf of user B. All of these programs will gain access to C when userB is added to the access list for C. There is no way to grant object access to a single program B without potentially granting access to other programs as well.

In a capability system, the transfer is restricted to program B, because the capability is transfered only to program B. The default situation is that other programs do not gain access to the object.(http://www.eros-os.org/faq/basics.html#wha tis-capability)

As soon as you break into a program which has a certain capability, you can transfer this capability to another program.

The result is exactly the same: You're potentially granting access to all other applications. Still not secure.

The most secure solution for very restricted data sharing is still compartment mode and information labeling.
Modern unix environments use a combination of access lists (for access to objects), capabilities (for process privileges) and capability inheritance controls. One of these systems is the only Operating System which is evaluated at the TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)

---

There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).

IBM's S/38 (the predecessor of the AS/400) had a capability-based access control, which needed only one initial security check, and then used the capability to allow access to a certain object.
Object reuse protection was available, because neither S/38's nor AS/400's ever reuse a virtual memory address.

On the AS/400 the capability flag in object pointers can't be used by user space applications any more, because of the problems related with revoking access to objects after a process has been granted access to an object by giving it a capability. Only the SLIC kernel allows itself to hold capabilities.

Another very important thing (perhaps the most important thing at all) is, that a capability is nothing else than a piece of data which can be used by a program - for example, a pointer with a certain bit set or cleared, indication valid authority (security checks performed) or invalid authority (security checks not performed).

Therefore you also need to protect these pointers from modification (IBM's AS/400 has pointer protection for object pointers built into the hardware, but don't confuse this with space pointers - this has only little to do with protection from buffer overflows and such, it's more like protected mode on other platforms, because AS/400s have a virtual single level store and for this reason you need some kind of protected pointer; complicated, as u can see).

So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.

---

I'd recommend you read 'Fortress Rochester'. This book was written by Frank Soltis, the system architect of the S/38 and the AS/400; in his book he explains some of the problems involved with capability-based access control, and why capabilites have been moved out of (even hardware protected!) system pointers on the AS/400.

Re:Further complicating the *nix security system

[Peaker]

What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.

This is an implementation detail. In EROS, for example, pages are never deleted. The "object" capabilities that actually refer to another process's object, are actually START capabilities that are easily deleted (or more accurately invalidated) efficiently, without risking reuse of revoked access. To support page deletion, you have to simply add another indirection level, which is not very expensive.

But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.

Ofcourse different processes that obey the same code (the same program, so to speak) (in other words, different instances of the program) have different sets of capabilities. This is not at all complicated.

Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on ..

I have discussed this -- There is no global namespace accessible to all processes. There can easily exist a program that implements a namespace (database or hierarchy-like file system) for the user's convinience, but it still does not lend a global namespace for all processes. Then, the user can take capabilities to objects from this namespace, and pass them on selectively to both his mp3 player and his mail client - not limiting his options at all.

As soon as you break into a program which has a certain capability, you can transfer this capability to another program.

The result is exactly the same: You're potentially granting access to all other applications. Still not secure.

I believe you have failed to understand the point behind the cited text. Bugs are not being discussed here - but the level of fine-grained security. Its merely saying that user-based access control lists force me to grant access to all of dan's programs, if I want to grant access to any of them. I cannot select which program I want to grant access to.

If you have two-way communication with a program, you can still exploit/abuse it, but in capability systems, you can restrict the communication of programs such that they can only communicate with a select few.

TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)

This is highly subjective and depends on your definition of a "design flaw".

There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).

There is nothing particularly difficult about sharing data in a capability system - you can easily share memory by passing a capability to the same page and mapping it into both of your address spaces.

So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.

Yes, capabilities are protected by the small trusted kernel-level code base. Yes, this requires a system call per-invocation. But capabilities are only invoked to perform IPC and to request kernel-level services so this is not worse in performance than a *nix variant.

Re:Finer-grained privs. Linux 2.5 has them too. +/

[tweakt]

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.

It would seem to me, given source code, one could easily determine each and every syscall the program could possibly make. Perhaps programs could progamatically drop those certain priveledges it doesn't need, just like now how apache will drop from uid root after binding to port 80? The "fork" privelege, once dropped lets say, can never be reaquired. It would be really nice in an auditing sense, to be able to look at a process and see the list of priveledged syscalls.

Re:ACLs on users rather than binaries?

[octogen]

It's not about ACLs, it's about privileges.

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 .comPack works, which is an EAL4 (exceeding B1) kernel security addon for Solaris and AIX.

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.

Don't get me wrong, I like capabilities security..

[scrytch]

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.

Multiple privilege levels

[coyote-san]

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.)

Re:Sorry but MacOSX is based on Mach kernel and so

[Anonymous Coward]

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."

Style.

[Grendel Drago]

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

Cheap: Re:Doesn't any READ ?

[Black Copter Control]

Does this mean X will run slightly slower compared with an suid installation?

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.

Re:That'll ensure the need of trained sysadmins ag

[Dogcow]

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.

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 /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).

Better yet...

[TheSHAD0W]

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.