lkml.org 
[lkml]   [1999]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: file effective and process inheritable mask
Date
Y2K writes:
> On Fri, 23 Apr 1999, Albert D. Cahalan wrote:

>> The two most important extensions IMHO are:
...
>> 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.
>
> How about CAP_LINUX_RESERVE_NORMAL_0 through CAP_LINUX_RESERVE_NORMAL_15
> being defined for future caps which are new caps that presently availible
> to everyone even non-root ones.

How many is enough? I do not think we should reserve a particular number
of slots. Also, that only covers the first problem.

Let's imagine that it is 2003, Linux 3.0 is out, and everybody is using
capabilities. Someone decides to split CAP_DAC_READ_SEARCH into less
powerful components CAP_DAC_SEARCH and CAP_DAC_READ.

Do you change the meaning of an existing bit, or do you end up with
all three capabilities? If you have all three, how do they interact?
If you change the meaning of an existing bit, stuff will break.

If there is a "known set" fK associated with the file, it is safe to
redefine the old bit. New kernels will know that the executable does
not define the new bit, so they can set it equal to the old bit.

>> 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.
>
> Thats easily done and won't even break the draft just define the default
> fI to be pP&(CAP_LINUX_RESERVE_NORMAL_0 | ...
> |CAP_LINUX_RESERVE_NORMAL_15) for unmarked executable files.
> you might just save yourself some trouble and say fI=pP ;->

One (or both) of us doesn't understand the other I think.
What I propose could work like this:

1. The kernel calculates the draft capabilities. (call them d_pP, etc.)
2. The kernel calculates old-style values too. (call them o_pP, etc.)
3. The kernel has /proc-configurable masks. (call them p_pP, etc.)
4. This is done:

pP = (o_pP & p_pP) | d_pP;

When the mask is 0, we get draft behavior. When it is full, capabilities
can be inherited in a more normal manner.

One might place these in p_pP:

CAP_DAC_READ_SEARCH
CAP_KILL
CAP_NET_BROADCAST
CAP_IPC_LOCK
CAP_SYS_BOOT
CAP_SYS_NICE
CAP_SYS_RESOURCE

These could be left out:

CAP_CHOWN
CAP_DAC_OVERRIDE
CAP_FOWNER
CAP_FSETID
CAP_SETGID
CAP_SETUID
CAP_SETPCAP
CAP_LINUX_IMMUTABLE
CAP_NET_BIND_SERVICE
CAP_NET_ADMIN
CAP_NET_RAW
CAP_IPC_OWNER
CAP_SYS_MODULE
CAP_SYS_RAWIO
CAP_SYS_CHROOT
CAP_SYS_PTRACE
CAP_SYS_PACCT
CAP_SYS_ADMIN
CAP_SYS_TIME

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.072 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site