>From your writing it appears that you're assuming that the Linux kernel
contains true capability support. Unfortunatelly, this is not so. The Linux
kernel contains support for capability lists, which is a different concept than
true (or pure) capabilities. Since most of the people refer to what is in the
kernel as 'capabilities', the confusion is inherent as newcomers who have read
about computer security get an impression that the kernel contains a powerful
token (aka key/lock aka descriptor aka true (pure) capability) based security
mechanism, when it really contains a fundamentally broken and abandoned (by the
people who put it together) concept of POSIX privileges (aka capability lists).
People who have studied security systems have learned to make a clear
distinction between the two concepts as the similiarities (besides them both
being security mechanisms) between them usually boil down to the word
'capability'.
>> 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.
As they say, the proof is in the pudding, so by all means, feel free to pursue
your implementation. Using capability lists is usually the last mistake that
people make when designing their security components, so I'd expect to have
this topic brought up relatively soon again.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si- 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/