> 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.
Hrm, can you give me an example of where this would be needed, where the
inheritable mechanism won't work? Of course, you may be referring to the
current kernel hack to make 'root' stuff work, in which case this is a
compatibility measure for use during transistion to a system-wide
implementation of our capability lists? So the goal would eventually be
'no bits survive'?
> 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.
But eventually this will be properly handled in inheritable during
starup/login?
[snip file sets]
> > 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 ...
OK, so you're in favor of a model where the admin has a variety of
choices? I'm mostly cool with this, except on the point of storing uid
info in the executable; of course, there's no reason you _have_ to store
uid info in _every_ cap-enabled binary. For setuid-root marked
executables, I can see storing r/euid (since that info is otherwise not
available in the fs).
So yes, I can certainly work with a hybrid solution that gives me choices.
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/