On Tue, 2006-03-14 at 18:44 +0100, Arjan van de Ven wrote:
> So it seems we disagree some ;-) Lets gets some individual statements
> out then:
>
> 1) It's not feasible to enumerate all the bad things that can happen.
> I think we both agree on this based on your reaction.
Yes.
> 2) For something as complex as apache (extremely configurable and used
> that way in practice all the time, as well as full of plugins with an
> active 3rd party plugin ecosystem), it is equally impossible to
> enumerate all the things it needs to be able to do statically and
> upfront. At least without ending up with an effective "everything
> goes" policy which is useless.
>
> I'm guessing you don't agree with this.
I agree that the vendor-shipped policy is going to have to be fairly
permissive by default, with optional settings (e.g. booleans) for
tightening it up in certain predefined ways.
> 3) If you try anyway, and a situation you didn't think of happens
> because the admin configures it that way, the complexity of the
> policy that resulted is such that the admin no longer has a chance
> to fix it himself. Even when the admin might fix a simple 5 line
> policy situation (for example by relabling his new app as "does
> network" from "does no network"), expecting the admin to fix up
> a highly complex policy without creating wide open holes is
> a losing battle. Best case is he disables the lot and realizes he
> needs to keep his apache highly uptodate. Worst case is he thinks
> he's safe and never updates.
>
> I'm guessing you also don't agree with this.
I agree that typical sysadmins shouldn't have to write/edit .te files.
This is noted in the useability discussion from the SELinux summit
minutes, along with some initial steps toward solutions. Again, this
doesn't require changes to the mechanism, just better tools to give the
sysadmin options without requiring him to deal with the raw policy,
along with proper use of already existing tools that let us check
properties of the resulting policy against security goals.
> So that leaves a few options:
> * dynamic policy that adjusts to the configuration
> this is going to be of the same order of complexity as the
> configuration options are in the first place.
This was discussed at the summit; see the minutes, and is also already
being employed in some tools that are in an early state.
> * keep the policy simple but allow more than strictly needed, yet
> disallow things that are highly out of bound.
This is certainly doable with existing SELinux mechanism, and note that
the first part ("allow more than strictly needed") is consistent with
SELinux's model because you are still applying an overall bound on what
is allowed.
In short, we understand the problem, and solutions are in progress, but
they are properly done as higher level tools on top of the existing
mechanism, not as a fundamental reworking of it.
> The parallel to firewalls has been made several times. But in fact the
> linux firewall does exactly this; the "related" ruleset is a dynamic
> behavior that allows more than strictly would be needed to be allowed,
> yet it's an effective way to keep things tight when you know they can
> be.
--
Stephen Smalley
National Security Agency
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
