On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas(a)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.
My NSA Security Enhanced Linux packages
Bonnie++ hard drive benchmark
Postal SMTP/POP benchmark
My home page