LWN: Comments on "Novell releases AppArmor"

Novell releases AppArmor

etbe — 2006-01-17T02:43:29+00:00

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.

Novell releases AppArmor

nix — 2006-01-16T11:55:19+00:00

I concur. Powerful (if less powerful than SELinux) and usable enough that mortal non-professional paranoids can write policies :)

(The low performance hit is a nice extra too.)

Novell releases AppArmor

nix — 2006-01-16T11:53:47+00:00

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

etbe — 2006-01-14T00:27:20+00:00

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

nix — 2006-01-13T21:05:07+00:00

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

davecb — 2006-01-13T13:59:53+00:00

I used to work on B2 Multics, and never even noticed that
they 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
"secret" "confidential" and "unclassified", not
labels like filenames.

--dave

Novell releases AppArmor

davecb — 2006-01-13T13:56:47+00:00

This is a **very** nice approach.

--dave (former professional paranoid) c-b

Novell releases AppArmor

nix — 2006-01-12T13:29:39+00:00

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!)