Messages in this thread | | | Subject | Re: suidpid( UID, credential? ) ? secure IPC? | Date | Tue, 07 Oct 1997 15:34:39 -0700 | From | Jim Dennis <> |
| |
> And lo, Jim Dennis saith unto me: >> I was wondering if there is any mechanism for having some >> process (a daemon or kernel module perhaps) "touch" a process >> and set its *real* UID to a different value. > Probably not.
I figured as much -- but an not an expert and figured a question would be a good way to introduct the topic.
> >> Would it make sense to add a suidpid() call? > What happens if, after authentication, the process dies and another > process pops up with the same PID? Hard to do nowadays, but I don't > believe it's guaranteed impossible, especially given some way of > bogging the authenticator down at the right moment...
I'd imagine that there would have to be a table of pending authentication calls (perhaps a circular buffer -- that generates some sort of ETIMEOUT to the oldest entry when its full). This table would have to be checked and updated as part of the kernel's process table maintenance (any process that does with a pending suidpid() call removes the entry in the pending table -- and perhaps even signals the reference monitor process).
> >> This would be a privileged system call that would allow a non-privileged >> program to request an suid change through any IPC mechanism we'd like >> to allow it to use. > If a privilege-requiring program is written correctly, it can be started > with privs and will get rid of them as appropriate. If it's written > incorrectly (e.g. vulnerable to buffer overrun compromise) it can use > this mechanism to gain privs anyway.
Experience has shown that many useful and popular programs are not written correctly. The major problem with the Unix security model is that it is very brittle. Any need to trust a program "a little bit" (with specific, well-defined capabilities) requires us to trust it "a lot." Its not possible to "give an inch" without offering "a mile."
We want ways to make finer grain delegations to processes -- things that are simpler and more compatible with existing source code than the MLS (Orange-Book/TCSEC B2) systems that I've heard about. Ideally we'd like
>> Imagine running popd, ftpd, login, su, sudo as "nobody" with no >> SUID bits and having them talk to some sort of "setuserd" daemon -- >> passing their request and credentials to them through ?? (some >> secure IPC). >> Then having the "setuserd" (or whatever we'd call it) able to >> grant that request. > Imagine running popd, ftpd, login, su, sudo written correctly. :-)
This is brittle. It is similar to saying:
We don't need all these pesky file permissions and all that VMM protection. Properly written programs will only access the files and memory regions that they're "supposed to."
Let's move all of the protections stuff out of the kernel and make each program responsible for checking the file's ownership and permissions -- we'll make all the compilers to bounds checking.
Spend a few weeks on Bugtraq or 8lgm and read the number of exploits that involve SUID. This has been going for over 25 years. This seems like a vast amount of empirical evidence that there is a problem with the programming model and/or the SUID mechanism.
Now we can continue to hold the (clearly unrealistic) expectation that numerous types of useful program *must* be trusted with excessive features (which I will call the "head in the sand" approach) or we can explore ways to improve the situation.
I've chosen to do a little bit of brainstorming on the latter approach. The message I posted here relates to the Linux kernel. Other those I've had (like the creation of a "sandbox" and the rewrite of numerous services and utilities to work within that sandbox) don't relate to the kernel -- or don't seem feasible under Unix (with any hope of applications level transparency or portability). >> What would be a suitably secure IPC mechanism? We'd want this setuserd >> or reference monitor to be able to "register" itself with the kernel >> in someway -- to keep the actually authentication in userland but without >> creating a hole whereby some random program could try to "become" the >> authorisor. > What, you want the authenticator not to require privs either? Yeesh.
I want the authenticator to have appropriate access to it's resources (perhaps read-only access to a password file) ... AND NO MORE.
I want the client to have appropriate access to the authenticator (secure, trustworthy IPC, of some sort).
I want the kernel to implement the minimum amount of the access method (the actually granting of access to the privileged resources.
... This doesn't seem like an unreasonable set of requirements. All I've asked about here is the kernel related aspects of the job. This is the old, provide mechanisms not policies.
>> If we had all that -- could a similar method be used to request access >> to other privileged system calls or to other resources. Could we have >> a mechanism where the requesting programs essentially says: >> >> I'd like this sort of access (read, write, append, execute) >> to this file -- here's a "capability" or "token" for it. >> >> ... and have some other process authorize the access and grant the >> access. >> >> If we had a few primitives of this sort we might be able to have a >> full featured "capabilities" subsystem running under Linux -- in such a >> way as to permit many normal programs to run, unmodified, with the help >> of some small wrappers. > What "normal" programs need capabilities?
Every daemon and SUID program that has ever been exploited to violate security, every program that has ever corrupted or damaged some file was unrelated to it's normal operation, every trojan horse -- in short they system needs finer grain access controls and mechanisms (and I don't mean just ACL's).
> Keith
Have you read about KeyKOS, EROS, Hydra, and other capabilities systems?
-- Jim Dennis (800) 938-4078 consulting@starshine.org Proprietor, Starshine Technical Services: http://www.starshine.org PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org> Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
| |