[cap-talk] SELinux (was "ACLs don't" paper rejected from Oakland 09)

Rob Meijer capibara at xs4all.nl
Tue Feb 10 03:19:56 EST 2009


On Tue, February 10, 2009 03:33, James Morris wrote:
> On Sat, 7 Feb 2009, Matej Kosik wrote:
>
>> James Morris wrote:
>> PS: Let us suppose that gedit is an example of untrusted piece of
>> software (which indeed is) and we want to follow POLA while using it. It
>> consists of 70980 lines of C code which we are not willing to read.
>
> Technically, you can apply POLA principles to gedit with SELinux, although
> for a general purpose system, the policy would need to be implemented with
> a high-level of granularity.  You could, for example, prevent it from
> accessing the network (even if the user's ambient authority said
> otherwise), but you would likely not be able to ensure it only accessed
> files the user really wanted it to access.  This is an inherent limitation
> of schemes which implement system-wide static security policy.

I believe it would be more a limitation in schemes that use label based
system-wide static security policy. In a path based system-wide static
security policy, hard linking (ln) could fill much of the gap that passing
open file descriptors leaves you with.

It may be interesting to see a label based free delegation setup, and
there doesn't seem to be a real fundamental issue with such a system, but
it seems however that most of the MLS/SELinux/LSM crowd are of the type of
people that feel that even the insightful UNIX provisions allowing us to
use open file descriptors (for files and networking sockets) as capability
like delegatable tokens were clueless and wrong, and even need fixing.

> (There is probably some useful hybrid approach, although that's a
> different discussion).

For such hybrid approaches including my own, at this point in time, path
based solutions such as AppArmor seem to be much more suited and much more
compatible than label based approaches such as SELinux. Even more so given
the general view on delegation of most of the the main developers of these
respective systems.

Rob




More information about the cap-talk mailing list