On Sat, 17 Apr 1999, Albert D. Cahalan wrote:
[snip]
> The /bin/mv executable has bits set in fI. Normal users should not
> get any special rights when they run /bin/mv, but the admin should
> gets a few capability bits in pP when running it.
>
> For /bin/mv, the bits are:
>
> fI == 00000000fffffeff
> fP == 0000000000000000
> fE == 0000000000000000
>
> Your system would not give /bin/mv the capabilities it needs to have.
> I think you were expecting that pP would contain something, and that
> a normal user would have bits set in pI. These are bad assumptions.
>
> In the "pP' = fP | (fI & pI)" expression you can see that the admin
> gets power from the "(fI & pI)" part, while normal users can only get
> power from the "fP" part.
Exactly. This is an assumption I've been kind of making, but it hasn't
been said out loud enough yet. Not to say that a few normal users might
not have a few bits set in pI...
[snip]
> No, we need a set of bits (I'll call it "pm") that are always added to pP.
> The set would be 0 for maximum security or normal users, and ~0 for an
> admin on a more normal system. This might be help kill off the ugly hack
> in exec.c that pretends an executable has fI and fE full if UID 0 runs it.
Well, we should certainly get rid of all uid=0=special code; treatment for
fI and fE should be configurable (under /proc somewhere?), as you'll want
differnt defaults during development of a new, capability-enhanced distro.
> new_pP = fP | (fI & old_pI) | old_pm;
> if(new_pP & ~old_pM) return -EPERM; /* getting prohibited caps? */
> if((new_pP & fm) != fm) return -EPERM; /* not enough? */
OK, I think the min and max values are already implicit in the fI and fP,
you merely insure that neither fI nor fP is a superset of the max caps
from the get-go. For the minimum, it's possible the binary will get caps
from fP and fI that still won't be sufficient; I say just let it fail,
much as 'chown bin myfile' always failed in the past.
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/