Novell releases AppArmor [LWN.net]

Novell releases AppArmor

Posted Jan 14, 2006 0:27 UTC (Sat) by etbe (subscriber, #17516)
In reply to: Novell releases AppArmor by nix
Parent article: Novell releases AppArmor

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"...

(Log in to post comments)

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 can
create 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.