Protecting processes,binaries with capabilities

[Robert Watson]

On Tue, 8 Aug 2000, Casey Schaufler wrote:

> Robert Watson wrote:
>
> > So, I've been working on the capability-enabled TrustedBSD environment,
> > and wanted to briefly raise the issue of protection of privileged
> > processes.  In the standard BSD environment, processes that spawn from
> > setuid/setgid binaries, or have previously had privilege (started with
> > uid0) are protected from some amount of interference from other processes
> > without privilege, even if they have the same uid.  Typically, this
> > protection involves preventing debugger access to the process, access to
> > its address space via /proc, limiting of signals that can be delivered,
> > etc.
> 
> We do the same on Irix. We also enforce rules regarding shared
> library paths, which some people dislike.

I've been working my way through system binaries, converting them to using
capabilities instead of setuid, and came across the following situation:
suppose a binary (previously setuid) executes other binaries.  It relies
on their correct behavior for its own functioning.  In a setuid world, it
doesn't give up privilege, so is assured that the programs it executes are
immune from tampering.  In a capabilities world, it might be desirable to
do the same, but not setting inheritable on the capabilities results in
the child being unprotected from tampering.

One possible solution would be to have all capability-flagged programs
relinquish effective before executing trusted (but not capability-enabled)
binaries, while retaining permitted and inheritable, which would continue
to protect the process.  This would require programs that are used with
capabilities to be careful about executing things -- probably not a bad
idea, so this is my favored choice.

Another would be to have set the "inheritable" bit on all capabilities in
trustable binaries, and using a combination of the inheritable bit and
bits set in the parent to choose to continue protecting the child.  On the
other hand, this might break situations where a process intentionally
gives up rights and expects not to have the child protected: i.e., su to
another user.

So I lean towards choice one, but was wondering how other people had dealt
with this problem.

For those that are interested, I should have my latest set of capability
patches for FreeBSD up on the www.trustedbsd.org web site sometime this
evening.  They rely on some supporting code I committed to the -CURRENT
branch this afternoon, to provide convenient wrapper functions for
accessing EAs within the kernel.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message