Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathnamematching

From: david
Date: Sat Jun 09 2007 - 00:57:26 EST


On Fri, 8 Jun 2007, Sean wrote:


On Sat, 9 Jun 2007 11:01:41 +0900
Tetsuo Handa <from-lsm@xxxxxxxxxxxxxxxxxxx> wrote:


From the discussion so far, it seems that the different "model" that AA
is trying to implement, is to do in one step what SELinux does in two
steps; that is trying to combine labelling and enforcement into a
single step. If this is so, then why can't it just feed its automatic
labelling into SELinux enforcement code?

I tried to give each file it's own label, but I couldn't do it.
http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf

That paper seems entirely focused on the automatic generation of policy,
and doesn't seem to help the discussion along. For instance, there may
be a way to implement AA on top of SELinux _without_ giving each and
every file its own label.

There are many elements that forms too strong barrier between pathname and labels,
such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
So I gave up giving each file a label that can be used as an identifier,
and took an approach to forbid unneeded mount operations, unneeded link operations,
unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.

AA must have a function that decides the security rights for any given
path in order to make its enforcement decisions. It must surely be able
to deal with all those things you listed above (bind-mounts,hard links etc).
So why can't those decisions be turned into labels that are fed into SELinux
enforcement code?

with AA hardlinks are effectivly different labels on the same file

one of the big problems with SELinux is what label to put on new files (including temp files), the AA approach avoids this (frequent) problem entirely. In exchange AA picks up the (infrequent) problems of bind-mounts and hard-link creation. People have tried to equate these prolems to show that AA has just as many problems as SELinux, but you can run systems for decades without creating hard-links or bind-mounts

also you seriously misunderstand the AA approach

AA does NOT try to create a security policy for every file on the system.

Instead AA policies are based on specific programs, and each policy states what files that program is allowed to access.

if you are useing AA to secure all exposed services on a box you don't have to try to write a policy to describe what gcc is allowed to access (unless through policy you give one of your exposed services permission to run gcc, and even then I'm not sure if gcc would inherit restrictions from it's parent or just use it's own)

the resulting policy is much easier to understand (and therefor check) becouse it is orders of magnatude smaller then any comprehensive SELinux policy.

the AA policy is also much easier to understand becouse you can look at it in pieces, understand that piece, and then forget it and move on to the next piece.

for example, if you write a policy for apache that limits it's access to it's log files, install directories, and document root. then you write a policy for your log analysis tool to access it's libraries, report directories (under the apache document root) and the apache log files (read only), these two policies are independant, you don't have to think about one while creating the other (which you would have to do if you had to put one label on apache binaries, another on normal web documents, a third on the reports, a fourth on the log files, and a fifth on the binaries for the log analysis tool. and this is ignoring any overlap in libraries!)

AA also lets a sysadmin dip their toe in the water and just write a policy for Apache, not for anything else, then write a policy for firefox, then write a policy for their mail client, then for bittorrent, etc. there is no need or push to try and secure everything all at once, and no need to re-label files (and change any policies that used the old labels) when you discover a new interaction.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/