lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: file effective and process inheritable mask
Date
David L. Parsley writes:
> On Sun, 25 Apr 1999, Albert D. Cahalan wrote:
>> I propose two things:
>>
>> 1. per-bit selection of traditional and draft behavior
>
> erm, did I miss something here? Can you bring me up to speed on what this
> is?

The startup scripts write some data to a config file in /proc which
determines which pP bits may survive an exec. You get the draft if
none of the bits survive. This allows a compatibility vs. security
tradeoff on a bit-by-bit basis.

Example policy:
Bits that only allow a DoS attack will survive an exec.
Bits that provide more power do not survive.

When I set up a system, I can let the real-time scheduling and memory
locking abilities be passed across an exec. The ability to overwrite
any file is much more dangerous, so I set that bit to draft behavior.

>> 2. David's bit set that reduces pI content
>
> what about 3. fm=min caps to run else EPERM ?

Oh yes, I forgot that one.

> Just to be sure I'm not completely off base here, this is what it looks
> like to me for current file cap sets (5 total):
>
> fP, bits explicitly raised in Permitted
> fI, bits Inheritable from parent
> fE, Effective bits initially set (yes, I agree we should go ahead and
> include this full set)
> fM, inheritable Mask, this adds security by restricting pI from always
> passing unrestrained to the child
> fR, (suggested nomenclature) Required capabilities; i.e., if the parent
> process doesn't have the necessary pI for the child to run properly,
> it fails with EPERM. This would occur, for example, when a normal
> user tries to execute a system service which needs to inherit
> certain bits to run, such as CAP_NET_BIND_SERVICE. This also has
> the potential to protect from certain DoS attacks, and shortcuts
> ugly error conditions.

Yes, I like that name.

> I'm curious, though, where everybody stands on setuid0 vs. ext2 bit.

It is absurd to argue over this. The concept of "trust" should be totally
independent of the features that rely on it. Filesystems should provide
a VFS function to query for trust, and mount options to determine what
attributes grant trust.

I want to be able to trust _everything_ on a CD-ROM, or nothing at all.
By default I want to trust setuid executables if and only if they are
enabled anyway. The RSBAC patches could provide an alternate way to
mark an executable as trusted, or could handle the data alone.

mount -t ext2 -o trustroot,trustimmutable,trustuid=1 ...

-
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site