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

[James Morris]

On Sat, 7 Feb 2009, Matej Kosik wrote:

> James Morris wrote:
> >
> > This work is not complete (e.g. protection needs to be extended throughout 
> > the X framework, which is ongoing; and these ideas could be generalized to 
> > cover all content parsing & processing), although it does seem workable as 
> > a useful security enhancement in the case of retrofitting an existing OS.
> 
> Do you also plan to confine/sandbox ordinary applications such as
> `gedit' (simple text editor like Notepad on MS Windows) ?

Not for general purpose use, as far as I'm aware.  The goals in Fedora, 
for example, are to protect the integrity of the system, and to contain 
vulnerabilities in network facing services.

There are some instances of confinement of general applications, although 
generally as part of a wider goal.  One example is in kiosk mode, where 
firefox is invoked in a confined security context such that general 
filesystem writes are not permitted, to prevent the user from downloading 
malicious executables.  The policy also ensures that firefox is the only 
way for the user to access the network.

> What kind of policy is, according to you, appropriate ?

It depends on the security goals of the system.

You could design a highly constrained system where the user is only able 
to access specific applications for specific purposes (e.g. a "web admin" 
who can only edit the web server configuration file), although the policy 
would be static in nature, and I gather you're thinking in terms of 
dynamic policies.

> Can it be enforced via SELinux ?
> 
> Did someone already write it ?
> 
> 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.

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


- James
-- 
James Morris
<jmorris at namei.org>