-----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@xxxxxxxxxx> 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----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
