> Paul Cassella wrote:
> > I think this can be done with one program that can grant arbitrary
> > capabilities, say /bin/caps, as in your scheme. /bin/caps would take a
> > command and argument like, say, strace or time, but would just acquire and
> > relinquish the "right" capabilities and then do the exec().
> you can't *grant* capabilities to a running process, you can only revoke
> your own. That's the whole idea behind it.
> otherwise. The only way that anything can get more caps than the
> executing process has right now, is by letting it do by the kernel
> during exec.
If there is a capability that says "I can have any capability I ask for",
then it could work this way. However, assuming that something like this
would be a bad idea, it could be modified by having the kernel give
/bin/caps, or whatever you've put into /proc/sys/kernel/caps, all
capabilities when it is exec'd. /bin/caps could then drop the ones the
resulting process shouldn't have before exec'ing it.
> something like this:
[snip daemon description]
One problem I see with this is that the fork()'d processes become children
of the daemon, not of the calling process. This could be vaguely
simulated, for most purposes of wait() and kill(), but it would be really
hairy.
> fine for a user table, however how can you figure out if somebody swaped
> your executable while you weren't looking ? a capability must be tied
Checksums or timestamps or something could be kept in the conf files if
you're paranoid, but I can see an argument that if you've given
capabilities to a binary that untrusted users can play with, that's what
you wanted to do, and the kernel shouldn't assume that it's smarter than
you.
> stronger than that to a specifique executable. specially if you allow
> capabilities to user execs.
Under this system, a user can only grant capabilities that they have. If
they grant their capabilities to a program that users they don't trust can
muck with, that would seem to be policy again, and userspace can enforce a
policy that forbids this, by /bin/caps checking the timestamps and
checksums and so on before exec'ing the program.
On the other hand, if there is a second user with root-like filesystem
capabilies, and no others, then they would be able to get any capabilities
that the first user had and gave to the executable. I don't know if it
makes sense to protect against this, though, because this root-like user
could modify, for example, the capabilities config files, and any other
config files stored on the filesystem, thereby obtaining any capability
anyway. But any capabilities system that stores information on disk is
subject to this, because a user with root-like filesystem rights could
edit the raw device, anyway.
> but you would still need to modify all existing programs.
Huh? All that needs to be done to existing programs is to create a
wrapper script around programs that want extra capabilities.
-- Paul Cassella :: Doctor Who: He's back, and it's About Time. fortytwo@cmu.edu :: http://www.contrib.andrew.cmu.edu/~pwc
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/