[OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Russell Coker]

On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas at austin.ibm.com> wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity.  This complexity makes it very hard to audit, and assure

What auditing are you referring to?  Kernel code, application code, or policy?

The application code is not overly complex.  The kernel code is as good as 
such code can be.  Tresys http://www.tresys.com/ are developing tools for 
auditing SE Linux policy.

> oneself that its actually providing any real security, as opposed to
> the illusion of security.  During this email thread, there are
> references to mysterious rules that neither party in the conversation
> fully understands; this scares me.

Which mysterious rules are you referring to?

> Compare that to this thread, where we are talking about atomic vs.
> non-atomic restoration of context for udev-mounted temp file systems.
> Shudder. This seems to be begging for an exploit to be discovered.
> Are we sure that SELinux is really on the right track here?

The original udev implementation had the device nodes relabelled after 
creation.  As of recent times (since 2002) the default SE Linux policy has 
denied almost all domains (only two system domains) access to device nodes 
labelled as device_t.  This means that there is no window of opportunity for 
an attacker to access a device before it is correctly labelled.

The worst race condition attack would be a DOS attack, cause an access at the 
wrong time and have it be denied when otherwise it would be permitted.  This 
is the least serious of all possible problems related to device labelling.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page