[lkml]   [1997]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: suidpid( UID, credential? ) ? secure IPC?

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

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

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

Jim Dennis (800) 938-4078
Proprietor, Starshine Technical Services:
PGP 1024/2ABF03B1 Jim Dennis <>
Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A

 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans