Given fine-grained privs exist, I submit to you that the "chmod" approach
(i.e. amplification authorized by a human, who has restricted who may
run the program if that is necessary) is much better than any way of
teaching a computer to figure out which processes to amplify privs for.
A computer can't judge a program's "intent", and that intent won't survive
a bug or compromise anyway. Most any "give remote user local access" break-ins
can be chained to "give local user privs" break-ins anyway; there's no need
to build the second half of that into the OS. 1/2 :-)
> >> 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.
I think the only thing here that really needs doing in the kernel is the
extending of privs back to the original requestor. The need to do this
(and all the "make the requestor hold still long enough" problems) can be
eliminiated by providing a service, not merely authentication. Especially
when the priveleged operation is a subset of a kernel-supported privelege,
there's no sense in giving the whole loose priv to each requestor, plus
revocation of the right to a service is much easier than revocation of
some priv you may or may not have granted sometime in the last few years...
And that still doesn't put "who should be authenticated" in more computer-
understandable terms...
> >> 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).
I'm not asking what programs need finer-grained permissions; I'm asking what
programs need capabilities per se. Proper use of setuid (to uid's other
than root) and standard UNIX groups and priveleges are as close to capabilites
as anyone will ever need for most things. Proper implementation of
capabilities requires that every capability-protected access be checked
by the kernel, and that capabilites themselves be directly accessible only
with privelege (to prevent spoofing and unauthorized propagation). Checking
to see if a process has a particular capability means searching through its
entire list of capabilities. Plus, something (the kernel) has to keep track
of what all those capabilities actually mean, at least by algorithm if not
by list...
> Have you read about KeyKOS, EROS, Hydra, and other capabilities
> systems?
I've read about capabilities in general, and the name Hydra rings a bell;
I could drag out Silberschatz and Galvin should I feel the need for a
refresher. Personally, I like access lists much better, but your tastes
may vary.
Keith