No more selinux-policy-*-sources

Shahms King shahms at shahms.com
Tue Mar 14 16:19:51 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dennis Jacobfeuerborn wrote:
> Alan Cox wrote:
> 
>> On Tue, Mar 14, 2006 at 03:24:45PM +0100, Dennis Jacobfeuerborn wrote:
>>
>>> complex solutions. AppArmor looks more attractive to me because while
>>> it may not be perfect at least it's usable and easily understandable
>>> compared to selinuxes black wizardry.
>>
>>
>> Lots of things can look pretty but it doesn't mean they actually solve
>> the
>> fundamental problems. SELinux uses more complex ideas like roles
>> because in
>> the 1960s people working on this stuff realised the simple model actually
>> doesn't work.
> 
> 
> 
> I understand that but if this system that "solves the fundamental
> problems" is so complex that most people just turn it off then the gain
> in security you get is pretty much theoretical. Security isn't an
> all-or-nothing thing and right now there seems to be chasm between the
> very basic traditional Unix model and the very secure but extremely
> complex SELinux. It looks like AppArmor fits in quite well between these
> two extremes.
> 
> Regards,
>   Dennis
> 


I'm over-simplifying, but the main source of complexity in the current
SELinux environment is its comprehensive nature.  None of the security
models currently used in SELinux is particularly complex.  The MLS
security model is counter-intuitive, but it's also not currently used
;-P  As it stands, the confusing areas of SELinux itself mostly reside
at the intersection between the different models (i.e. how DAC identity
and SELinux identity interact, how roles and types relate, etc.) and
with the myriad of object classes and associated permissions.

The task of specifying a comprehensive policy using only the DAC model
would be as daunting a task as doing so for SELinux is currently.  The
only difference is that DAC is inherently modular.  Securing your
average daemon/application is mostly a matter of asking two questions:

1. Who should be able to run this application?
2. What should the application be able to do?

Obviously both questions are overly-simplistic, but both are readily
answerable and the answers to both questions translate pretty directly
into a reasonable policy.  Taking, for example, an anonymous-only ftp
daemon:

1. It should be run from the init scripts by the system or administrator
2. It should be able to:
 a. read it's configuration from /etc
 b. listen on port 21 and 20
 c. read files and directories under its root
 d. append to a log file

That's pretty much it (off the top of my head).  A number of those
translate to multiple permissions (specifically 2c).  Given a base
policy I could write an application specific policy using the above
information.  Admittedly, I know more about SELinux than most, but with
a little more work the above could be turned into a couple of macros or
interfaces that could be used easily by application packagers with
relatively little knowledge of the details.  Even enabling full
read-write support for authenticated users (and authenticating those
users) and an associated boolean for switching between the two should be
relatively easy to write and/or macro-ize.

This post turned out longer than I expected, but the point is that
SELinux's reputation for incomprehensible complexity is undeserved.
It's new, different, and relatively undocumented but with a little
refinement should be no more difficult to deal with than the current DAC
security model and provides real security unlike AppArmor.

- --
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEFu0n/qs2NkWy11sRAqiTAKCwgIKMTRepNQdbx5o/Zh7ayeomxgCfS8jh
frtZiRS9qL+32nuH/2tpNT0=
=hnhd
-----END PGP SIGNATURE-----




More information about the fedora-devel-list mailing list