unsubscribe

[Fraser Cringan]

-----Original Message-----
From: fedora-selinux-list-bounces at redhat.com
[mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Stephen Smalley
Sent: Thursday, September 02, 2004 11:11 AM
To: Fedora SELinux support list for users & developers.
Cc: linux-hotplug-devel at lists.sourceforge.net; SELinux; Bill Nottingham;
Colin Walters; Nigel Kukard; harald at redhat.com
Subject: Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
> Hmm, I thought I understood MAC; I was refering to the large numbers of
> rules in SELinux.  Its not obvious (to me) that there isn't a path
> through those rules that allows privledge escalation.  
> 
> For example: and correct me if I'm wrong, but its quite possible to 
> write a complex rule set that intentionally leaves 'holes' allowing
> for priveledge escalation.  Thus, by extrapolation, its quite possible
> to write a set of rules that accidentally do the same.  When one is
> presented with a set of rules, how does one know that they don't have a
> hole? Answer: one audits the rules.  Unfortunately, there are a lot
> of rules: last time I looked at one of the config files, it was
> thousands of lines long.  Thus, a short, simple audit performed by
> one person seems out of the question.

The complexity of the rules reflect the complexity of the existing Linux
system and its interactions; SELinux didn't introduce that complexity -
SELinux just enables you to control what happens in that complex
system.  No criticism intended of Linux; the same would apply to any
mainstream operating system, and the complexity just reflects real world
requirements.  And you do have the option of reducing the visible
complexity based on your security goals; if you don't care about the
interactions among a set of processes/resources, you fold the domain and
type space accordingly.  The targeted policy is an example of doing that
to an extreme.

Analysis of that complexity _does_ require automated tools, and such
tools exist.  apol (yum install setools setools-gui) provides support
for analysis, including domain transitions and information flow.  slat
(available from the NSA SELinux site or MITRE) does security goal
checking using a model checker.  Gokyo from IBM Watson (which AFAIK is
unfortunately not released publically yet, perhaps you could encourage
that to happen) analyzes against Biba integrity constraints and
identifies exceptions for further examination.

> However, the SELinux rules
> are unlike the kernel in an important way: they are config files. 
> This allows allows some anonymous fedora/debian/gentoo maintainer
> to do something dumb like "gee, my USB camera doesn't work with udev,
> but then when I change this selinux rule, it does", and poof, you've
> lost the security.

The policy maintainers for the various distros are not anonymous and
appear to take their work quite seriously; rejecting policy changes
despite a reduction in functionality is not uncommon.  You seem to be
assuming that policy for each package is maintained by the individual
package maintainers; that isn't the case, and likely never will be. 
Ditto for sysadmins; most of them should never touch policy at all.

> What I'm proposing here is that bluntness can be traded for increased
> assurances and increased ability to audit the code for "correctness". 
> Yes, SELinux is far more flexible; but this is exactly what scares me.

Reality is complex.  Deal with it.  Being confident in the correctness
of an inadequate security model doesn't help much.

> I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
> I'm pretty sure that this is possible, but I started thinking that the
> complexity of the ruleset may introduce holes that voids the effort.
> And that thought disturbed me.

It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.

> Along with Lomac's 'bluntness' comes 'zero configurability': its
> something that could be installed on the proverbial 'Grandma's Linux
> desktop', and provide additional security without causing pain.

Until Grandma wants to do useful work.  Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done.  SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list