>> 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...
Note that this system does not allow an admin to have some power that
just works with every unmarked executable. It isn't even a config option.
Such a feature would allow a more secure but still UNIX-like behavior.
>> 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.
Just how configurable? You would need to have:
1. some bits that are 0
2. some bits that are 1
3. some bits that are 1 for root and 0 for others
Ugh. You still don't kill the special treatment for root. This won't do.
>> 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,
Please explain how to do this:
1. there exists a program called a.out that everyone can run
2. there are two admins, avatar and super
3. there a capability called CAP_X
4. avatar can run everything with CAP_X
5. super only gets CAP_X when running a.out
Now add:
6. there is a restricted user that must _never_ get CAP_X
(the normal users get CAP_X via fP, but this user can't do that)
Add this too:
7. there is a buggy executable called b.out that must never get CAP_X
(avatar wants to run this executable)
> [...] 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.
This is very bad. When 'chown bin myfile' always failed in the past,
every single privileged operation failed. With the new system, you
can have partial failures. This can really make a mess with programs
that expect to perform multiple operations.
-
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/