On Fri, 23 Apr 1999, Albert D. Cahalan wrote:
>
> David L. Parsley writes:
>
> > real-world use. One is that the file effective set seems superflous;
> > i.e., if the program is _not_ capability aware, the effective set for the
> > new process should just be equal to the permitted set, otherwise the
> > program won't be able to accomplish it's job; if it _is_ capability aware,
> > then it should manipulate it's own effective set. So really, I still
> > don't see why we need fE (file effective).
>
> Consider these types of marked executables:
Note: pE and pP are what I'm concerned with...
> dumb, without privilege fE should be empty
or pE'=pP'=0
> dumb, with privilege fE should be equal to fP
or pE'=pP'=fP || (fI && pI)=(something); in other words, whatever this
program can get in it's permitted needs to be raised in effective; a
raised permitted bit which isn't effective is useless (for a 'dumb' prog)
> smart fE should be empty
why not pE=pP initially, and let the 'smart' program continue to
manipulate pE as it desires?
> We really only need one bit to indicate if an executable is aware,
> but there is no harm in using a whole set of bits.
I just want to keep our implementation fairly spartan, without much
clutter. fE just doesn't look very useful to me, and especially not for
security purposes. As Andrej Presern pointed out, an exploit can
trivially raise all effective to match permitted anyway.
> > Two, (and I'm thinking mostly here about non-cap-aware binaries),
> > it seems like it would be nice to be able to constrain the passage of the
> > inheritable set using our cap-elf model. I'm referring to an fM, where it
> > masks off bits in the inheritable by the formula pI' = pI && fM. This
> > occurs to me after thinking about an admin account starting a program by
> > hand, where the shell might have a mostly full inheritable set. This
> > seems like a bad security issue, since that program can exec() another
> > program with a more potent inheritable set.
>
> You are supposed to be able to do that.
Certainly! That's the whole point of the way inheritable passes between
processes. I'm just saying that, in looking at designing a secure system
around caps, there are many cases where I _don't_ want inheritance to pass
in the usual fashion. Some programs just have no business exec'ing
another process and giving it elevated privs. Running named, mountd,
imapd, portmap, etc with pI=(mostly full) makes them just as vulnerable to
buffer overflow exploits as before; i.e., they could exec /bin/sh and get
a shell with mostly raised pI=='root shell'. So by including an fM, I can
prevent programs from getting a full pI when they don't need it. This,
IMHO, is perfectly in line with the principle of least priviledge.
> Think of it being a bit like the
> ability to run a normal setuid-root executable. Normal users are allowed
> to do that. It would be silly to only let already-privileged users run
> privileged executables.
>
> The fI vs. fP distinction lets you have capabilities that are activated
> for a subset of the users, those who already have the bits in pI.
Right, but 'more' has no business having CAP_SETFCAP in it's pI under
_any_ circumstances. (well, none legitimate that I can think of) So
having CAP_SETFCAP in it's pI is a pretty big priviledge that we currently
have no good method for removing.
> > I've read that the idea is for privs to be able to pass though a
> > chain of programs which themselves may have little or no pP, which is
> > fine, but IMHO it would be nice to stop this effect for many binaries.
> > (still thinking of named, telnetd, ... system services)
>
> The draft model does not seem to provide this ability. It could in fact
> be dangerous, since privileged executables with poor error checking could
> crash when they get insufficient capabilities.
I'm only talking about privs that have no business whatsoever being passed
on in the inheritable set. If a distribution maintainer masks out a priv
that is legitimately _needed_ by sub-processes, that's their own fault,
and easily correctable.
> Besides confusion and tech support trouble, crashes can allow DoS attacks
> and possibly worse.
>
> The two most important extensions IMHO are:
>
> 1. The ability to mark an executable with the minimum capabilities
> needed to properly execute. This helps avoid crashes.
Well, I've tried to illustrate a broad class of problems that appear to
require the solution I've suggested. I can certainly _see_ what you're
talking about here, but I can't think of any good examples that would
cause any real problems. If this is really a corner case you're talking
about here, it may be best solved in other ways (patching the program,
since not error-checking is an obvious bug). I'm just thinking it's not
efficient to store this extra info if <1% of cap-enabled programs really
need it. On the other hand, the abscence of fM seems to require patching
a _lot_ of programs to make them capability-aware.
> 2. The ability to mark an executable with the capabilities that were
> known to the setup tool. The kernel can use default values for any
> bits that are not listed. This lets kernel developers add new bits
> for traditionally unprivileged operations and lets them split old
> bits into more fine-grained sets of bits.
OK, this 'future-proofing' is something I haven't really given much
thought to, but I can see how it could become an issue. I'll try to think
about this today some.
> After those two, I think it would be nice to allow configurations that
> are halfway between traditional behavior and the draft. One could let
> the more harmless capabilities (resources, read access...) be passed
> to child processes automatically, while enforcing the draft behavior
> for more destructive capabilities.
Well, I can see the need for quite a few files in /proc/... to tune
default behavior; and this is fairly cheap.
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/