"Stephen C. Tweedie" <sct@redhat.com> writes:
> On 16 Apr 1999 11:52:11 +0200, Christian von Roques
> <roques@scalar.pond.sub.org> said:
> > "Stephen C. Tweedie" <sct@redhat.com> writes:
> >> [...] It is to prevent privileges leaking, so that bugs in these
> >> daemons do not compromise the security of other parts of the OS.
> > Therefore there should be a privilege to exec(2), if there isn't
> > already, which most daemons should deny themselves.
> No, that's not necessary. The trick is that exec()ing a new process
> doesn't automatically transfer the current process's privileges to the
> new program. In a capabilities model, the exec() drops all currently
> held privileges unless the new program is specifically marked to be able
> to inherit certain privileges.
Yes, this is in theory as safe as denying exec(2). The few attacks
I've seen tricked the targeted daemon into exec()ing a shell and used
that. Suppose an attacker wants to create/modify a file to influence
the system. Going through a shell would still be feasible in a system
using capabilities, as the shell probably is marked to inherit some
basic privileges like creating/reading/writing files, directories,
and sockets. Without exec(2) the attack has to trick the daemon into
doing the malicious stuff itself, which in theory is not any harder,
but might be more inconvenient for the attacker.
A exec(2)-capability probably wasn't such a good idea after all, as
many daemons have a need to exec(2): sendmail -> procmail, ftpd -> ls,
bind -> named-xfer, finderd -> finger, ...
Christian.
-
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/