> On Mon, 12 Apr 1999, David L. Parsley (lkml account) wrote:
> >> who says the [root owned] +s, capability-enabled binaries need to be +x ?
> > ^^^^^^^^^^^^
> >IMHO, that's the problem right there. In a true capabilities-based
> >system,
>
> You keep mentioning a 'true capabilities-based system' when you're realy
> discussing a mutilated capability LIST design.
Capabilities themselves are already written into the kernel, and I
currently am just assuming that the code for propogating capabilities
through an 'exec' is already in there. What remains is to store the three
capability sets for each executable in the filesystem in a secure way. The
right (and future) way to do this is through new filesystem metadata. What
I am proposing gives us a logical equivalent, but is immediately
compatible with all current tools, and in it's current incarnation appears
very secure (Eric Biederman having solved the older kernel problem). The
remaining problem is with networked filesystems, which, by guaging some
opinions, shouldn't hold capability-enabled binaries in any case.
> Please don't confuse the two,
> obviously different, concepts.
Please expand, I'm not following.
> As for the 'topic', your fundamental problems lie not in the dillema of using
> sticky and suid bits. Your fundamental problems lie in the inadequacy of the
> POSIX privileges concept to provide a competent security mechanism and in the
> nature of existing subsystems and mechanisms which were not designed with
> security in mind but actively participate in the security subsystem - both of
> which manifest in the ad-hoc-ness of the proposed solution(s).
Our ad-hoc solutions merely give us the filesystem component of a
capabilities-based system. User space tools need some work, but can
operate in this system quite nicely by merely being capability enabled.
Take 'tar' for instance; leave it's 'permitted' bits 0, and raise (at a
minimum) CAP_SETFCAP in it's inheritable set. Then, it may be that at
login the authenticated user gets a bash shell with CAP_SETFCAP raised in
it's inheritable set, thereby allowing that user (security-officer?) to
unpack a .tar.gz and preserve caps. A normal user unpacking should
produce non-capability-enabled binaries. Similar techniques apply to cp,
et. al, and IMHO are right-on with true capability support.
> Andrej
>
> --
> Andrej Presern, andrejp@luz.fe.uni-lj.si
- --
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/