Message-ID: <hh8g17$qlu$1@taverner.cs.berkeley.edu>
Date:	Sun, 27 Dec 2009 20:28:23 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: A basic question about the security_* hooks

>Sure, it's *possible* to create a system where you've loaded 2 security systems
>and have it work.  But the general consensus is that if you're running one
>system and want to run a second, it's easier to ask yourself *why* you want to
>run the second, and see if there's some way to get the added functionality
>supported in the first system.

Read the thread, where you can find the answer *why*.  The question has
already been answered.  As far as I can tell, the answer is not what you
are presuming.  As far as I can tell, the answer is, the original poster
wants a simple, fairly high-assurance, easy-to-configure way to disable
network access for certain processes, to facilitate privilege-separated
software architectures.  That's a great goal.  It's a goal that is not
easily supported by, say, SELinux.

So now suppose you are starting with a system that's running SELinux,
and you want to add functionality to meet the original poster's goals.
What do you do?  You've basically got two choices: (a) hardcode it in,
ignoring the LSM hooks; or (b) build a little LSM that enforces this
using the LSM hooks.

If you go with approach (a), Alan Cox gives you a hard time and says
"this ought to be done with a LSM".

If you go with approach (b), you're dead in the water: because people
have a kneejerk reaction against ever allowing composition of LSMs,
there's no way to use your own little LSM on your system (without
turning off SELinux or whatever LSM was already installed -- and
this cure is arguably worse than the disease).

It's a catch-22.  What are you supposed to do?  The poster has asked for
your advice about the best way to accomplish his goals, and is open to
any approach that meets these goals.  So far all I have heard is "No".
I think folks could be more constructive.

I think people have committed a logical fallacy here: they've reasoned
that in the general case, composition is hard to reason about, therefore
all composition must be bad.  The "therefore" does not follow.

>The basic problem is that large complete MAC systems like TOMOYO, SELinux,
>Smack, or AppArmor are complicated.  In addition, they are unable to look at
>each other's policies to detect potential conflicts. As a result, although
>it's probably *possible* to create a system that loads both a TOMOYO and
>an SELinux policy, it's hazardous:

But that's irrelevant.  Re-read the thread.  The poster doesn't want
to compose TOMOYO+SELinux.  He wants to compose SELinux+his little LSM.
Or AppArmor+his little LSM.  Or (whatever LSM was already installed)+his
little LSM.  TOMOYO+SELinux is a strawman.

The fact that composing TOMOYO+SELinux is hazardous says little or nothing
about the merits of composing SELinux+his little LSM.  His little LSM
is, well, little, and as a result likely to be noticeably easier to
reason about.  Sure, there may be tricky corner cases.  Sure, there
could be subtle hazards lurking here.  But don't jump immediately to
the worst case when the worst case isn't what's at issue here.

Yes, composition is hard.  Look, software is hard.  We suck it up
and deal with it.  We make the best of it.  We choose architectures
that minimize the likelihood of breakage.  (And in many ways that is
the kind of thing the original poster has done, and is open to doing.)
But we don't give up and say, oh forget about this software stuff,
it's too hard, let's go to the beach instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists