| |||||||||||||
Novell releases AppArmorNovell releases AppArmorPosted Jan 12, 2006 13:29 UTC (Thu) by nix (subscriber, #2304)Parent article: Novell releases AppArmor
I've been avoiding SELinux because of its sheer complexity and overdesign: I don't need labelled security, and neither does anyone else I know: filenames are perfectly adequate labels. This looks *much* more maintainable (as in `practical for a mortal human to write a set of policies'). It's very nice that there's now a demarcation between `coarse root-only security' and SELinux.
(And, hey, something that uses capabilities for something near their intended purpose! Wow!)
(Log in to post comments)
Novell releases AppArmor Posted Jan 13, 2006 13:59 UTC (Fri) by davecb (subscriber, #1574) [Link] I used to work on B2 Multics, and never even noticed thatthey were running mandatory security. I've since lived for some years with a Trusted Solaris 7 system, and only the sysadmin was different. I expect SE Linux will become as easy to use.
And, just by the way, the labels are things like
--dave
Novell releases AppArmor Posted Jan 13, 2006 21:05 UTC (Fri) by nix (subscriber, #2304) [Link] Well, yes, except that in SELinux all security policies are applied to types (which are a labelling scheme of sorts, therefore). This means that you end up needing a *lot* of types and a massive tangle of relationships between files, types, and security policies...
... I can see that it's more flexible than AppArmor, but ye gods is it also more complex, and TBH most of us just don't need that complexity.
Novell releases AppArmor Posted Jan 14, 2006 0:27 UTC (Sat) by etbe (subscriber, #17516) [Link] In the Unix permission scheme (IE user, group, and other having RWX bits)the file name is NOT used for access control. If for example I use the "mv" command to rename a file it will have the same permissions after the rename operation. Any MAC system which does not control access based on the Inode (as SE Linux does with XATTRs that are associated with the Inode) will not preserve the same semantics as Unix permissions in regard to renaming files. Then there's the issue of hard-links. In Unix file systems a file with hard links does not have one canonical name, each of the hard links can be considered equally authoritative. When access is based on a regular expression and you have two different regexes matching different hard links to a file then you have different access granted to a file depending on which name you use to access it. For a comprehensive MAC system you want to be able to audit the policy. For example to secure the /etc/shadow file we want to know which domains can read/write it and which programs can be used to enter those domains so that we know which programs to audit to verify that there is no possibility of stealing or changing passwords. Such analysis is not possible when the programs that have access to the shadow file may have different labels depending on which name is used to access them. A further complication of AppArmor is that file paths seem only valid within a file system. So if /home is a separate file system then a hostile user could request that the administrator give them an account name which matches a regular expression for some system files. Think about if a user had an account named "lib" or "opt"...
Novell releases AppArmor Posted Jan 16, 2006 11:53 UTC (Mon) by nix (subscriber, #2304) [Link] Well, as I understand it AppArmor uses the filename to *look up* the inode number and then tags the inode. Obviously no other system would be secure under hardlinks, especially if as standard POSIX semantics demand any user can hardlink files owned by other users into directories they control. (I think it reasonable to assume that any system designed by Crispin Cowan wouldn't have a design flaw as large as you imply in it!)
Obviously the AppArmor globbing/regexing thing is something which should be used with care: don't put wildcards at the front of the name!
What might really cause problems for AppArmor, and for any filename-based system, is wide use of filesystem namespaces. If /etc/shadow refers to a different file depending on the PID, what do you do?
(Mind you, this screws up conventional Unix security as well. I think that no matter what you do to the filesystem namespace, / and /etc had better remain non-writable by anyone but root.)
Novell releases AppArmor Posted Jan 17, 2006 2:43 UTC (Tue) by etbe (subscriber, #17516) [Link] With SE Linux there are access controls to determine which processes cancreate a hard link to a file. For example with the strict policy most processes on the system are not permitted to create hard links to files in /etc. I believe that some of the Common Criteria certifications require that the system label Inodes not file names so any system that doesn't do something similar to what SE Linux does will not do well in certification. In a conventional Unix system there is nothing preventing you from having a /etc/shadow file in a chroot environment with different permissions to the "real" one. A bigger problem for AppArmor is the fact that file specs are relative to the root of a file system. So /etc/shadow is equivalent to /home/etc/shadow if /home is a separate file system.
|
|||||||||||||