AppArmor security module overview

Quoted 20 lines · --- Stephen Smalley

Quoted 12 lines · Casey Schaufler

Quoted 2 lines · --- Greg KH

A daemon using inotify can "instantly"[1] detect this and label the file properly if it shows up.

In our 1995 B1 evaluation of Trusted Irix we were told in no uncertain terms that such a solution was not acceptable under the TCSEC requirements. Detection and relabel on an unlocked object creates an obvious window for exploitation. We were told that such a scheme would be considered a design flaw.

Quoted 6 lines

I understand that some of the Common Criteria labs are less aggressive regarding chasing down these issues than the NCSC teams were. It might not prevent an evaluation from completing today. It is still hard to explain why it's ok to have a file that's labeled incorrectly _even briefly_. It is the systems job to ensure that that does not happen.

Quoted 2 lines

Um, Casey, he is talking about how to emulate AppArmor behavior on a label-based system like SELinux,

Yes. What I'm saying (or trying to) is that such an implementation would be flawed by design.

Quoted 2 lines

not meeting B1 or LSPP or anything like that
(which AppArmor can't do regardless).

We're not talking about an implementation based on AppArmor. As you point out, we're talking about implementing name based access control as an extension of SELinux.

Quoted 5 lines

As far as general issue
goes, if your policy is configured such that the new file gets the most restrictive label possible at creation time and then the daemon relabels it to a less restrictive label if appropriate, then there is no actual window of exposure.

Is it general practice to configure policy such that "the new file gets the most restrictive label possible at creation time"? I confess that my understanding of the current practice in policy generation is based primarily on a shouted conversation in a crowded Irish pub.

Quoted 3 lines

Also, there is such a daemon, restorecond, in SELinux (policycoreutils) although we avoid relying on it for anything security-critical naturally.

Yes, I am aware of restorecond. I find the need for restorecond troubling.

Quoted 3 lines

And one could introduce the named type transition concept that has been discussed in this thread without much difficulty to selinux.

Yup, I see that once you accept the notion that it is OK for a file to be misslabeled for a bit and that having a fixxerupperd is sufficient it all falls out.

Quoted 10 lines

Quoted 7 lines

I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is "if possible", and in fact "if possible" is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible.

In particular, to layer AppArmor on top of SELinux, the following problems must be addressed:

Quoted 7 lines

* New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says "/home/*/.plan r" to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux.

A daemon using inotify can "instantly"[1] detect this and label the file properly if it shows up.

Quoted 3 lines

* Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename.

Same daemon can do the re-label.

Quoted 3 lines

* Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files.

Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in "real-life" on a "production" server is quite small, if at all.

Hi!

And before you scream "races", take a look. It does not actually add them:

Quoted 18 lines

Quoted 17 lines

Quoted 7 lines

I agree that the in-kernel implementation could use different abstractions than user-space, provided that the underlying implementation details can be hidden well enough. The key phrase here is "if possible", and in fact "if possible" is much too strong: very many things in software are possible, including user-space drives and a stable kernel module ABI. Some things make sense; others are genuinely bad ideas while still possible.

In particular, to layer AppArmor on top of SELinux, the following problems must be addressed:

* New files: when a file is created, it is labeled according to the type of the creating process and the type of the parent directory. Applications can also use libselinux to use application logic to relabel the file, but that is not 'mandatory' policy, and fails in cases like cp and mv. AppArmor lets you create a policy that e..g says "/home/*/.plan r" to permit fingerd to read everyone's .plan file, should it ever exist, and you cannot emulate that with SELinux.

Quoted 2 lines

A daemon using inotify can "instantly"[1] detect this and label the file properly if it shows up.

Or just create the files with restrictive labels by default. That way you "fail closed".

From my limited knowledge of SELinux, this is the default today so this

Quoted 5 lines

Quoted 3 lines

* Renamed Files: Renaming a file changes the policy with respect to that file in AA. To emulate this in SELinux, you would have to have a way to instantly re-label the file upon rename.

Same daemon can do the re-label.

...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does not add a new race relative to AA.

Quoted 7 lines

Quoted 3 lines

* Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files.

Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in "real-life" on a "production" server is quite small, if at all.

And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors.

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Quoted 2 lines

Or just create the files with restrictive labels by default. That way you "fail closed".

From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to verify or fix my understanding of this?

Quoted 6 lines · Greg KH

Quoted 2 lines

Or just create the files with restrictive labels by default. That way you "fail closed".

From my limited knowledge of SELinux, this is the default today so this would happen by default. Anyone with more SELinux experience want to verify or fix my understanding of this?

This is entirely controllable via policy. That is, you specify that newly create files are labeled to something safe (enforced atomically at the kernel level), and then your userland relabeler would be invoked via inotify to relabel based on your userland pathname specification.

This labeling policy can be as granular as you wish, from the entire filesystem to a single file. It can also be applied depending on the process which created the file and the directory its created in, ranging from all processes and all directories, to say, just those running as user_t in directories labeled as public_html_t (or whatever).

Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees.

So, so much for the "it's going to be too slow re-labeling everything" issue, as it's not even required for almost all situations :)

On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner

Quoted 2 lines · --- James Morris

On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner

That's an eternity for that many files to be improperly labeled. If, and the "if" didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the "safe" argument. They've been known to balk before.

Quoted 6 lines · Casey Schaufler

Quoted 2 lines · --- James Morris

On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner

Quoted 6 lines

That's an eternity for that many files to be improperly labeled. If, and the "if" didn't originate with me, your policy is demonstrably correct (how do you do that?) for all domains you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the "safe" argument. They've been known to balk before.

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames.

There is no expectation that this scheme would be submitted for certification.

Its purpose is to merely to provide pathname-based labeling outside of the kernel.

Quoted 14 lines · --- James Morris

Quoted 11 lines · Casey Schaufler

Quoted 2 lines · --- James Morris

On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner

That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal. I can't say if an evaluation team would buy the "safe" argument. They've been known to balk before.

Quoted 4 lines

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy always ensures a safe label on a file, and then relabeling newly created files according to their pathnames.

To counter clarify:

You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.

I have no questions about 2. It's a hack, but you've already acknowledged that and it will work, allowing for some potential cases where someone is overeager about getting a file-in-transition.

Regarding 1: This is a founding premise of the arguement, that the "policy" is written correctly such that there is no case where a file gets created with an unsafe label. Given the external nature of the policy, and the number of attributes used within the policy, and the overall sophistication of the policy mechanism, how does one ...

a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required

The question is not if fixxerupperd can set things right. The question is about the properly written policy that is required to make the mechanism worth discussing.

Quoted 2 lines

There is no expectation that this scheme would be submitted for certification.

De-nial.

Quoted 2 lines

Its purpose is to merely to provide pathname-based labeling outside of the kernel.

If you already have an in-kernel labeling scheme that you trust to make the world safe until you get around to doing the labeling externally you can argue that it's good enough. But, to quote Cinderella's Stepmother, "I said "if"".

Quoted 3 lines · Greg KH

Oh great, then things like source code control systems would have no problems with new files being created under them, or renaming whole trees.

It depends -- I think we may be talking about different things.

If you're using inotify to watch for new files and kick something in userspace to relabel them, it could take a while to relabel a lot of files, although there are likely some gains to be had from parallel relabeling which we've not explored.

What I was saying is that you can use traditional SELinux labeling policy underneath that to ensure that there is always a safe label on each file before it is relabeled from userspace.

Quoted 2 lines

So, so much for the "it's going to be too slow re-labeling everything" issue, as it's not even required for almost all situations :)

You could probably get an idea of the cost by running something like:

$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar

On my system, it takes about 1.2 seconds to label a fully checked out kernel source tree with ~23,000 files in this manner, on a stock standard ext3 filesystem with a SATA drive.

Quoted 8 lines · Pavel Machek

Quoted 8 lines

Quoted 4 lines

* Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files.

Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in "real-life" on a "production" server is quite small, if at all.

Quoted 4 lines

And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors.

Agreed.

Quoted 8 lines

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Exactly.

I can't think of a "real world" use of moving directory trees around that this would come up in as a problem.

Maybe a source code control
system might have this issue for the server, but in a second or two everything would be working again as the new files would be relabled correctly.

Can anyone else see a problem with this that I'm just being foolish and missing?

Quoted 10 lines · Greg KH

Quoted 8 lines · Pavel Machek

Quoted 8 lines

Quoted 4 lines

* Renamed Directory trees: The above problem is compounded with directory trees. Changing the name at the top of a large, bushy tree can require instant relabeling of millions of files.

Same daemon can do this. And yes, it might take a ammount of time, but the times that this happens in "real-life" on a "production" server is quite small, if at all.

Quoted 6 lines

Quoted 4 lines

And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors.

Agreed.

We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem.

Quoted 10 lines

Quoted 8 lines

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Exactly.

You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue.

Quoted 2 lines

I can't think of a "real world" use of moving directory trees around that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else.

Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache.

In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say "get it now, going away in 10 minutes" and then move it out again. Yes, you can manually address this by running "restorecon ~crispin/public_html". But AA does this automatically without having to run any commands.

You could get restorecon to do this automatically by using inotify.

But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance.

This problem does not exist for SELinux, because SELinux does not expect access to change based on file names.

This problem does not exist in the proposed AA implementation, because the patch makes the access decision based on the current name of the file, so it doesn't have a consistency problem between the file and its label; there is no label.

The problem is induced by trying to emulate AA on top of SELinux. They don't fit well together. AA fits much better with LSM, which is the reason LSM exists.

Quoted 5 lines

Maybe a source code control
system might have this issue for the server, but in a second or two everything would be working again as the new files would be relabled correctly.

Try an hour or two for a large source code repository. Its linear in the number of files, and several hundred thousand files would take a while to relabel. A large GIT tree would be particularly painful because of the very large number of files.

Quoted 3 lines

Can anyone else see a problem with this that I'm just being foolish and missing?

It is not foolish. The label idea is so attractive that last September from discussions with Arjan we actually thought it was the preferred implementation. However, what we've been saying over and over again is that we *tried* this, and it *doesn't* work at the implementation level. There is no good answer, restorecon is an ugly kludge, and so this seductive approach turns out to be a dead end.

Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels.

Quoted 17 lines · Crispin Cowan

Quoted 11 lines · Greg KH

Quoted 8 lines · Pavel Machek

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Exactly.

You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Quoted 4 lines

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue.

Quoted 8 lines

Quoted 2 lines

I can't think of a "real world" use of moving directory trees around that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else.

Quoted 3 lines

Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache.

Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up.

Quoted 7 lines

Quoted 3 lines

Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache.

Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up.

on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result.

Ok, so mv gets slower for big trees... and open() gets faster for deep trees. Previously, open in current directory was one atomic read of directory entry, now it has to read directory, and its parent, and its parent parent, and its...

(Or am I wrong and getting full path does not need to bring anything in, not even in cache-cold case?)

Quoted 18 lines · Greg KH

Quoted 17 lines · Crispin Cowan

Quoted 11 lines · Greg KH

Quoted 8 lines · Pavel Machek

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Exactly.

You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Quoted 7 lines

Quoted 4 lines

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue.

how do you 'fix' the laws of physics?

the problem is that with a directory that contains lots of files below it you have to access all the files metadata to change the labels on it. it can take significant amounts of time to walk the entire three and change every file.

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

I can't think of a "real world" use of moving directory trees around that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else.

Quoted 7 lines

Quoted 3 lines

Under the restorecon proposal, the web site would be horribly broken until restorecon finishes, as various random pages are or are not accessible to Apache.

Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up.

on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result.

Quoted 6 lines

Quoted 3 lines

Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up.

on the contrary, useing 'mv' is by far the cleanest way to do this.

Quoted 4 lines

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result.

I agree, and yet, somehow, SELinux today handles this just fine, right? :)

Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users.

Quoted 12 lines · Greg KH

Quoted 11 lines

Quoted 3 lines

Usually you don't do that by doing a 'mv' otherwise you are almost guaranteed stale and mixed up content for some period of time, not to mention the issues surrounding paths that might be messed up.

on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate
thousands
to millions of permission changes as a result.

Quoted 2 lines

I agree, and yet, somehow, SELinux today handles this just fine, right? :)

no it doesn't, SELinux as-is should take no action when the above command is run, but SELinux implementing path-based permissions will have to relabel every file or directory in both trees.

Quoted 3 lines

Let's worry about speed issues later on when a working implementation is produced, I'm still looking for the logical reason a system like this can not work properly based on the expected AA interface to users.

if you are willing to live with the race conditions from the slow (re)labeling and write the software to scan the entire system to figure out the right policies (and then use inotify to watch the entire system for changes and (re)label the appropriate files) and accept that you can't get any granular security for filesystems that don't nativly support it you could make SELinux behave like AA.

but why should they be required to? are you saying that the LSM hooks are not a valid API and should be removed with all future security modules being based on SELinux?

on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate thousands to millions of permission changes as a result.

Quoted 2 lines

We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem.

How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but "somehow" SELinux already handles this, so I think you should be fine.

Quoted 4 lines

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue.

Quoted 4 lines

Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue.

Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do the work.

What "kernel memory and performance" issues are there? Your SLED machine already has inotify running on every directory in the system today, and you don't seem to have noticed that :)

Quoted 8 lines · Greg KH

Quoted 2 lines

We have built a label-based AA prototype. It fails because there is no reasonable way to address the tree renaming problem.

How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but "somehow" SELinux already handles this, so I think you should be fine.

SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face.

How well does inotify handle running attached to every directory on a typical Linux system?

Quoted 7 lines

Quoted 4 lines

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the only problem we have here, it isn't an issue.

Restorecon traverses the filesystem from a specific down. In order to apply to an entire system (as would be necessary to try to emulate AppArmor's model using SELinux), restorecon would need to run on vast portions of the filesystem often. (mv ~/public_html ~/archived; or tar zxvf linux-*.tar.gz, etc.)

I'm not sure we need to run restorecon every time rename(2) is called.

Quoted 5 lines

Quoted 4 lines

Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue.

Quoted 4 lines

Agreed, so we fix that. There are ways to speed those kinds of things up quite a bit, and I imagine since the default SELinux behavior doesn't use restorecon in this kind of use-case, no one has spent the time to do the work.

The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very difficult to improve on this.

Quoted 3 lines

What "kernel memory and performance" issues are there? Your SLED machine already has inotify running on every directory in the system today, and you don't seem to have noticed that :)

I beg to differ. :)

Quoted 5 lines

How does inotify not work here? You are notified that the tree is moved, your daemon goes through and relabels things as needed. In the meantime, before the re-label happens, you might have the wrong label on things, but "somehow" SELinux already handles this, so I think you should be fine.

SELinux does not relabel files when containing directories move, so it is not a problem they've chosen to face.

The time for restorecon is probably best imagined as a kind of 'du' that also updates extended attributes as it does its work. It'd be very difficult to improve on this.

Quoted 10 lines · Crispin Cowan

Then there's all the other problems, such as file systems that don't support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable to network attack, but that is not the threat AA is addressing. AA is preventing an application with access to an NFS mount from accessing the *entire* mount. There is lots of practical security value in this, and label schemes cannot do it. Well, mostly; you could do it with a dynamic labeling scheme that labels files as they are pulled into kernel memory, but that requires an AA-style regexp parser in the kernel to apply the labels.

You still haven't answered Stephen's response to NFSv3, so until then, please don't trot out this horse.

- File systems that do not support labels: I'm a bit surprised that you would advocate this given your experience in developing EA and ACL support for local filesystems and NFS. The pathname-based approach in NFS seems even scarier than in the local case - the clients may have different views of the namespace than one another or the server and the potential for inconsistent views of the tree (particularly as it is being modified) during access checks is only greater in the NFS case, right? It may be more expedient to implement, but is it the right technical approach?

But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of things in the way the kernel works.

Quoted 4 lines · Greg KH

But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of things in the way the kernel works.

How exactly are struct vfsmount and struct dentry not in-kernel structures?

Quoted 8 lines

Quoted 8 lines

Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Quoted 2 lines

Exactly.

You are remembering old behavior. The current AppArmor generates only correct and consistent paths. If a process has an open file descriptor to such a file, they will retain access to it, as we described here:

Under the restorecon-alike proposal, you have a HUGE open race. This post http://bugs.centos.org/view.php?id=1981 describes restorecon running for 30 minutes relabeling a file system. That is so far from acceptable that it is silly.

Of course, this depends on the system in question, but restorecon will necessarily need to traverse whatever portions of the filesystem that have changed, which can be quite a long time indeed. Any race condition measured in minutes is a very serious issue.

Quoted 2 lines

I can't think of a "real world" use of moving directory trees around that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month, and testing it on the server by putting it in a different virtual domain. We want to go live at some particular instant by doing an mv of the content into our public HTML directory. We simultaneously want to take the old web site down and archive it by moving it somewhere else.

You could get restorecon to do this automatically by using inotify. But to make it as general and transparent as AA is now, you would have to run inotify on every directory in the system, with consequences for kernel memory and performance.

Quoted 3 lines

Can anyone else see a problem with this that I'm just being foolish and missing?

It is not foolish. The label idea is so attractive that last September from discussions with Arjan we actually thought it was the preferred implementation. However, what we've been saying over and over again is that we *tried* this, and it *doesn't* work at the implementation level. There is no good answer, restorecon is an ugly kludge, and so this seductive approach turns out to be a dead end.

I've caught up on this thread with growing disbelief while reading the mails, so much that I've found it hard to decide where to reply to.

So people are claiming that AA is ugly, because it introduces pathnames and possibly a regex interpreter. Ok, taste differs. We've got many different flavours of filesystems in the kernel because of that.

However, the suggested cure makes me cringe.

You're saying that relabeling file(s) from user-space after a rename is a possible solution.

This breaks POSIX - renames must be atomic. It is possibly insecure; if this is fixed by making a rename automatically default to restrictive permissions, it'll be even more inconvenient. It will break applications

You _must_ be kidding. The cure is worse than the problem.

If that is the only way to implement AA on top of SELinux - and so far, noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle, and for which there is demand.

The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function

inconvenient, yes, insecure, no.

I believe AA breaks POSIX, already. rename() is not expected to change permissions on target, nor is link link. And yes, both of these make AA insecure.

Quoted 1 line

You _must_ be kidding. The cure is worse than the problem.

Possibly.

Quoted 4 lines

If that is the only way to implement AA on top of SELinux - and so far, noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle, and for which there is demand.

What demand? SELinux is superior to AA, and there was very little demand for AA. Compare demand for reiser4 or suspend2 with demand for AA.

Quoted 2 lines

The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function

Which are exactly the bits Christoph Hellwig and Al Viro vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of VFS maintainer.

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

Quoted 2 lines

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

AppArmor doesn't actually provide confinement, because it only operates on filesystem objects.

What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless.

You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine.

Quoted 5 lines · James Morris

Quoted 2 lines

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

AppArmor doesn't actually provide confinement, because it only operates on filesystem objects.

Quoted 3 lines

What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless.

Only if they have access to another process which provides them with that data.

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

Quoted 3 lines

You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine.

If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.)

Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way.

The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your "protection" of desktop applications is easily subverted.

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
<snip>

Quoted 4 lines

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Yes. Your use case is different than mine.

not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry.

Quoted 9 lines · Lars Marowsky-Bree

On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
<snip>

Quoted 4 lines

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Quoted 2 lines

Yes. Your use case is different than mine.

So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry.

Quoted 9 lines · Joshua Brindle

Quoted 8 lines · Lars Marowsky-Bree

On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
<snip>

Quoted 1 line

Um, no. It might not be able to directly open files via that

path, but

Quoted 1 line

showing that it can never read or write your mail is a rather

different

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

matter.

Yes. Your use case is different than mine.

So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry.

remember, the policies define a white-list

so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem.

other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place.

Quoted 23 lines · [email protected] wrote:

Quoted 20 lines · Joshua Brindle

Quoted 4 lines · Lars Marowsky-Bree

On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
<snip>

Quoted 8 lines

Quoted 1 line

Um, no. It might not be able to directly open files via that

path, but

Quoted 1 line

showing that it can never read or write your mail is a rather

different

Quoted 2 lines

matter.

Yes. Your use case is different than mine.

So.. your use case is what? If an AA user asked you to protect his mail from his browser I'm sure you'd truthfully answer "no, we can't do that but we can protect the path to your mail from your browser".. I think not. One need only look at the wonderful marketing literature for AA to see what you are telling people it can do, and your above statement isn't consistent with that, sorry.

Quoted 2 lines

remember, the policies define a white-list

Except for unconfined processes.

Quoted 9 lines

so if a hacker wants to have mozilla access the mail files he needs to get some other process on the sysstem to create a link or move a file to a path that mozilla does have access to. until that is done there is no way for mozilla to access the mail through the filesystem.

other programs could be run that would give mozilla access to the mail contents, but it would be through some other path that the policy permitted mozilla accessing in the first place.

Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be.

Quoted 1 line

remember, the policies define a white-list

Except for unconfined processes.

Or through IPC or the network, that is the point, filesystem only coverage doesn't cut it; there is no way to say the browser can't access the users mail in AA, and there never will be.

Quoted 3 lines · Stephen Smalley

Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way.

Well, yes. That is intentional.

Your point is?

Quoted 6 lines

The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your "protection" of desktop applications is easily subverted.

That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation.

Quoted 3 lines

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Yes. Your use case is different than mine.

Quoted 2 lines

Yes. Your use case is different than mine.

My use case is being able to protect data reliably. Yours?

Quoted 4 lines · On Friday June 22, [email protected] wrote:

Quoted 2 lines

Yes. Your use case is different than mine.

My use case is being able to protect data reliably. Yours?

Saying "protect data" is nearly meaningless without a threat model. I bet you don't try to protect data from a direct nuclear hit, or a court order.

AA has a fairly clear threat model. It involves a flaw in a program being used by an external agent to cause it to use privileges it would not normally exercise to subvert privacy or integrity.
I think this model matches a lot of real threats that real sysadmins have real concerns about. I believe that the design of AA addresses this model quite well.

What is your threat model? Maybe it is just different.

From http://www.nsa.gov/selinux/info/faq.cfm:

Quoted 6 lines

Quoted 3 lines

Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way.

Well, yes. That is intentional.

Your point is?

It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories.

Quoted 2 lines

That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation.

IOW, anything that AA cannot protect against is "out of scope". An easy escape from any criticism.

Quoted 1 line

Yes. Your use case is different than mine.

My use case is being able to protect data reliably. Yours?

Quoted 5 lines · Stephen Smalley

Quoted 5 lines

Quoted 3 lines

Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way.

Well, yes. That is intentional.

Quoted 4 lines

Quoted 1 line

Your point is?

It may very well be unintentional access, especially when taking into account wildcards in profiles and user-writable directories.

Again, you're saying that AA is not confining unconfined processes. That's a given. If unconfined processes assist confined processes in breeching their confinement, yes, that is not mediated.

You're basically saying that anything but system-wide mandatory access control is pointless.

If you want to go down that route, what is your reply to me saying that SELinux cannot mediate NFS mounts - if the server is not confined using SELinux as well? The argument is really, really moot and pointless. Yes, unconfined actions can affect confined processes.

Quoted 4 lines

Quoted 2 lines

That is an interesting argument, but not what we're discussing here. We're arguing filesystem access mediation.

IOW, anything that AA cannot protect against is "out of scope". An easy escape from any criticism.

I'm quite sure that this reply is not AA specific as you try to make it appear.

Quoted 2 lines

Quoted 1 line

Yes. Your use case is different than mine.

My use case is being able to protect data reliably. Yours?

I want to restrict certain possibly untrusted applications and network-facing services from accessing certain file patterns, because as a user and admin, that's the mindset I'm used to. I might be interested in mediating other channels too, but the files are what I really care about. I'm inclined to trust the other processes.

Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't.

The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process).

And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to preventing exploitation.

Sorry, do you mean the "server" as in the "server system" or as in the "server daemon"? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel.

Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its limitations.

Quoted 2 lines

Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't.

Then yours isn't mandatory access control, nor is it confinement.

Quoted 11 lines · Stephen Smalley

Sorry, do you mean the "server" as in the "server system" or as in the "server daemon"? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel.

Oh, you're saying that this threat is out-of-scope? ;-)

Note that here we've already strayed from the focus of the discussion; we're no longer arguing "the implementation is ugly/broken", but you're claiming "doesn't do what I need" - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine.

If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way.

Quoted 3 lines

Quoted 2 lines

Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't.

Then yours isn't mandatory access control, nor is it confinement.

I apologize for not using the word "confinement" in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up.

So agreed, it is not confinement nor MAC.

Would it be more appropriate if I used the word "restricts" or "constrains"?

Quoted 13 lines · Lars Marowsky-Bree

Quoted 11 lines · Stephen Smalley

Sorry, do you mean the "server" as in the "server system" or as in the "server daemon"? For the former, I'd agree - we would want SELinux policy applied on the server as well as the client to ensure that the data is being protected consistently throughout and that the server is not misrepresenting the security guarantees expected by the clients. Providing an illusion of confinement on each client without any corresponding protection on the server system would be very prone to bypass. For the latter, the kernel can only truly confine application code, not in-kernel threads, although we can subject the in-kernel nfsd to permission checking as a robustness check. We've always noted that SELinux does depend on the correctness of the kernel.

Quoted 1 line

Oh, you're saying that this threat is out-of-scope? ;-)

Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it requires separate mechanism outside of SELinux itself.

Quoted 10 lines

Note that here we've already strayed from the focus of the discussion; we're no longer arguing "the implementation is ugly/broken", but you're claiming "doesn't do what I need" - which I'm not disagreeing with. It doesn't do what you want. Which is why you have SELinux, and it's going to stay. Fine.

If we assume that the users who run it do have a need / use case for it which they can't solve differently, we should really get back to the discussion of how those needs can be met or provided by Linux in a feasible way.

Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling).

If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, not me.

Quoted 10 lines

Quoted 3 lines

Quoted 2 lines

Your use case mandates complete system-wide mediation, because you want full data flow analysis. Mine doesn't.

Then yours isn't mandatory access control, nor is it confinement.

I apologize for not using the word "confinement" in the way you expect it to be used. I certainly don't want to imply it does do things it doesn't. Keep in mind I'm not a native speaker, so nuances do get lost sometimes; nor do I have long years of experience in the security field. Thanks for clearing this up.

Quoted 4 lines

So agreed, it is not confinement nor MAC.

Would it be more appropriate if I used the word "restricts" or "constrains"?

Yes. Or simply "controls file accesses and capability usage".

Mandatory access control as historically understood has always meant system-wide.

Quoted 7 lines · Lars Marowsky-Bree

Quoted 5 lines · James Morris

Quoted 2 lines

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

AppArmor doesn't actually provide confinement, because it only operates on filesystem objects.

Quoted 6 lines

Quoted 3 lines

What you define in AppArmor policy does _not_ reflect the actual confinement properties of the policy. Applications can simply use other mechanisms to access objects, and the policy is effectively meaningless.

Only if they have access to another process which provides them with that data.

Or can access the data under a different path to which their profile does give them access, whether in its final destination or in some temporary file processed along the way.

Quoted 2 lines

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

Quoted 5 lines

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA.

Quoted 11 lines · Chris Mason

Quoted 6 lines

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA.

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor.

AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right?

Quoted 12 lines · James Morris

Quoted 11 lines · Chris Mason

Quoted 6 lines

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA.

Quoted 7 lines

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

The above two paragraphs appear to contradict each other.

Quoted 3 lines

Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor.

Quoted 4 lines

AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right?

So if the document said "confinement with respect to direct file access and POSIX.1e capabilities" and that list got extended as AA got new confinement features, would that address your issue?

That would certainly help, although one might quibble with the use of the word "confinement" at all wrt AppArmor (it has a long-established technical meaning that implies information flow control, and that goes beyond even complete mediation - it requires global and persistent protection of the data based on its properties, which requires stable and unambiguous identifiers).

Quoted 10 lines · Chris Mason

Quoted 5 lines

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA.

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

Recall that the question asked by Lars was whether there were any outstanding technical issues relating to AppArmor.

AppArmor does not and can not provide the level of confinement claimed by the documentation, and its policy does not reflect its actual confinement properties. That's kind of a technical issue, right?

Quoted 10 lines · Chris Mason

Quoted 5 lines

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel summit. There are valid uses for path based security, and if they don't fit your needs, please don't use them. But, path based semantics alone are not a valid reason to shut out AA.

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

Quoted 6 lines

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model.

Quoted 9 lines · Chris Mason

Quoted 6 lines

The validity or otherwise of pathname access control is not being discussed here.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

I'm sorry, but I don't see where in the paragraphs above you aren't making a general argument against the pathname model.

There are two distinct concepts here.

A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves.

Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc.

Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door.

What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of "set your house into a rock wall so there is only one path to it".

B. Pathname access control as a general abstraction for OS security.

Which is what was being discussed above, in response to a question from Lars about technical issues, and that this _model_ doesn't generalize to the rest of the OS, regardless of whether you think the mechanism of pathname labeling itself is appropriate or not.

But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel.

We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit.

I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that?

Quoted 3 lines · Chris Mason

But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel.

Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one.

Until people understand these issues, they certainly need to be addressed in the context of upstream merge.

Quoted 3 lines

We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit.

I don't believe that people at the summit were adequately informed on the issue, and from several accounts I've heard, Stephen Smalley was effectively cut off before he could even get to his second slide.

I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then.

But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where:

while(1)
AA) we think we're making users happy with pathname security SELINUX) pathname security sucks

Quoted 6 lines · * Chris Mason ([email protected]) wrote:

I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then.

Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case). Retroactively creating the full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity).

Quoted 6 lines

But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where:

while(1)
AA) we think we're making users happy with pathname security SELINUX) pathname security sucks

Yes. Please. Both parties are miserably failing the sanity test. Doing the same thing over and over and expecting different results.

AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise). You've already missed an opportunity with Christoph's suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours.

SELinux folks: do something useful rather than quibbling over the TCSEC definition of MAC and AA's poor taste in marketing literature. Here's some suggestions:

1) Make SELinux usable (it's *still* the number one complaint). While this is a bit of a cheap shot, it really is one of the core reasons AA advocates exist.
2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
3) Write an effective exploit against AA that demonstrates the fundamental weakness of the model (better make sure it's not also an issue for targetted policy).

This thread is amazing. With so many smart people's precious time,

What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)

Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask.

Is this ml a place of judge or battle? (not to help or support?)

Nothing is perfect, so we can work to make things to better, right? I have suggestions:

Let's clarify issues first.
- problems (or limitations) of pathname-based MAC
- advantages of pathname-based MAC
- how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help)

Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help.

Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help.

BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC.
http://lkml.org/lkml/2007/6/13/58
AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues.

What I want to say is "let's make progress and help each other to make Linux better".

Quoted 7 lines · * Chris Mason ([email protected]) wrote:

I'm sure people there will have a different versions of events. The one part that was discussed was if pathname based security was useful, and a number of the people in the room (outside of novell) said it was. Now, it could be that nobody wanted to argue anymore, since most opinions had come out on one list or another by then.

Indeed. The trouble is that's too high level compared with the actual implementation details. AA is stalled because it has failed to get VFS support for it's model. I don't see a nice way out unless it changes it's notion of policy language (globbing is the tough one) or gets traction to pass dentry/vfsmount all the way down. Paths are completely relevant for security, esp. when considering the parent dir and the leaf (as in forward lookup case).

Retroactively creating the
full path is at the minimum ugly, and in the worst case can be insecure (yes AA has taken many measures to mitigate that insecurity).

AA folks: deal with the VFS issues that your patchset have in a palatable way (which does not include passing NULL when it's inconvenient to do otherwise).

You've already missed an opportunity with Christoph's
suggestions for changes in NFS. I know you've considered many alternative approaches and consistently hit dead ends. But please note, if you have coded yourself into a corner because of your policy language, that's your issue to solve, not ours.

But as someone who doesn't use either SElinux or AA, I really hope we can get past the part of the debate where:

while(1)
AA) we think we're making users happy with pathname security SELINUX) pathname security sucks

Quoted 3 lines · Chris Mason

But, this is a completely different discussion than if AA is solving problems in the wild for its intended audience, or if the code is somehow flawed and breaking other parts of the kernel.

Is its intended audience aware of its limitiations? Lars has just acknowledged that it does not implement mandatory access control, for one.

Until people understand these issues, they certainly need to be addressed in the context of upstream merge.

We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that?

Hi!

Quoted 5 lines

We've been over the "AA is different" discussion in threads about a billion times, and at the last kernel summit. I think Lars and others have done a pretty good job of describing the problems they are trying to solve, can we please move on to discussing technical issues around that?

Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected).

(Does it surprise you, too? I'm pretty sure it would surprise many users).

James summarized it nicely:

# The design of the AppArmor is based on _appearing simple_, but at the

# expense of completeness and thus correctness.

If even Lars can be surprised by AAs behaviour, I do not think we can say "AA is different". I'm afraid that AA is trap for users. It appears simple, and mostly does what it is told, but does not do _what user wants_.

Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/ allows any user to make AA ineffective on large part of systems -- in internal discussion. (It is not actually a _bug_, but it is certainly unexpected).

Argument 3. AA isn't complete until it mediates network and IPC.

Let me comment on these one-by-one.

3. This one I agree with. If you want to sandbox network daemons that you're concerned might get hacked, then you really want your sandbox to mediate everything. Right now the security provided by AA (if that's what you are using it for) will be limited by its incomplete mediation, since a knowledgeable motivated attacker who hacks your daemon may be able to use network or IPC to break out of the sandbox, depending upon the network and host configuration. Filesystem mediation alone might be better than nothing, I suppose, if you're worried about script kiddies, but it's certainly not a basis for strong security claims. The state of the art in sandboxing obviously requires complete mediation, and we've known that for a decade.

2. This is argument #1 in a different guise and I find it about as weak. Pathname-based access control has strengths and weaknesses. I think users and Linux distributions are in a better position to evaluate those tradeoffs than L-K. Competition is good.

I've heard four arguments against merging AA.

Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA.
Or: SELinux can do everything that AA can.)

Argument 2. Object labeling (or: information flow control) is more secure than pathname-based access control.

Argument 3. AA isn't complete until it mediates network and IPC.

Argument 4. AA doesn't have buy-in from VFS maintainers.

1. I think this is a bogus argument for rejecting AA. As I remember it,

3. This one I agree with. If you want to sandbox network daemons that

4. Way over my head. I'm not qualified to comment on this aspect. I suspect this is the argument that ought to be getting the most serious and thorough discussion, not the irrelevant SELinux-vs-AA faceoff.

A. Pathname labeling - applying access control to pathnames to objects, rather than labeling the objects themselves.

Think of this as, say, securing your house by putting a gate in the street in front of the house, regardless of how many other possible paths there are to the house via other streets, adjoining properties etc.

Pathname labeling and mediation is simply mediating a well-known path to the object. In this analogy, object labeling would instead ensure that all of the accessible doors, windows and other entrances of the house were locked, so that someone trying to break in from the rear alley would not get in simply by bypassing the front gate and opening any door.

What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of "set your house into a rock wall so there is only one path to it".

B. Pathname access control as a general abstraction for OS security.

To quote from:

http://www.novell.com/linux/security/apparmor/

"AppArmor gives you network application security via mandatory access
control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (including those that run as root) to thwart attempted exploits and even zero-day attacks."

This is not accurate in any sense of the term containment of mandatory access control that I've previously encountered.

The fact that it doesn't work as expected does not arise simply from missing features or being "different". It arises from the design of the system, which uses a pathname abstraction, where, even if we agree to ignore issue (1) above, still does not work, because only filesystem interactions are mediated.

The "simple" policy that users can so effortlessly manipulate is simple because it is wrong, and deliberately so.

The design of the AppArmor is based on _appearing simple_, but at the expense of completeness and thus correctness.

Quoted 3 lines

What you do with AppArmor, instead of addressing the problem, is just redefine the environment along the lines of "set your house into a rock wall so there is only one path to it".

Harrumph. Those analogies sound good but aren't a very good guide.

Let's take a concrete example. Consider the following fragment of a policy for Mozilla:
allow ~/.mozilla
deny ~
Ignore the syntax; the goal is to allow Mozilla to access files under ~/.mozilla but nothing else under my home directory. This is a perfectly reasonable policy fragment to want to enforce. And enforcing it in the obvious way using pathname-based access control is not a ridiculous thing to do.

The point is that the pathname model does not generalize, and that AppArmor's inability to provide adequate coverage of the system is a design issue arising from this.

Quoted 2 lines · Lars Marowsky-Bree

On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:

Quoted 2 lines

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

The emphasis on never modifying applications for security in AA likewise has an adverse impact here, as you will ultimately have to deal with application mediation of access to their own objects and operations not directly visible to the kernel (as we have already done in SELinux for D-BUS and others and are doing for X). Otherwise, your "protection" of desktop applications is easily subverted.

Quoted 4 lines

Quoted 3 lines

You might define this as a non-technical issue, but the fact that AppArmor simply does not and can not work is a fairly significant consideration, I would imagine.

Quoted 3 lines

If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.)

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Quoted 4 lines · Stephen Smalley

Quoted 2 lines · Lars Marowsky-Bree

On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:

Quoted 9 lines

Quoted 2 lines

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip.

We have never claimed to be using pathname-based mediation IPC or networking. The "natural abstraction" approach does generize well enough and will be analyzable.

Quoted 4 lines

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible.

Quoted 3 lines

No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip.

The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place.

I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly),

Quoted 5 lines · Stephen Smalley

Quoted 3 lines

No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip.

The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place.

That's an interesting claim, however I don't think it holds. AA was designed to mediate file access in a form which is intuitive to admins.

It's to be expected that it doesn't directly apply to mediating other forms of access.

Quoted 6 lines

I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly),

I seem to think that this is not what AA is trying to do, so evaluating it in that context doesn't seem useful. It's like saying a screw driver isn't a hammer, so it is useless because you have a nail.

Quoted 14 lines · John Johansen

Quoted 13 lines · Stephen Smalley

Quoted 5 lines · Lars Marowsky-Bree

On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation. And the "use the natural abstraction for each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

Quoted 3 lines

No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip.

The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place.

Quoted 3 lines

We have never claimed to be using pathname-based mediation IPC or networking. The "natural abstraction" approach does generize well enough and will be analyzable.

I think we must have different understandings of the words "generalize" and "analyzable". Look, if I want to be able to state properties about data flow in the system for confidentiality or integrity goals (my secret data can never leak to unauthorized entities, my critical data can never be corrupted/tainted by unauthorized entities - directly or indirectly), then I need to be able to have a common reference point for my policy. When my policy is based on different abstractions (pathnames, IP addresses, window ids, whatever) for different objects, then I can no longer identify how data can flow throughout the system in a system-wide way.

Quoted 6 lines

Quoted 4 lines

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Actually it can be analyzed and shown. It is ugly to do and we currently don't have a tool capable of doing it, but it is possible.

No, it isn't possible when using ambiguous and unstable identifiers for the subjects and objects, nor when mediation is incomplete.

Quoted 3 lines · John Johansen

No the "incomplete" mediation does not flow from the design. We have deliberately focused on doing the necessary modifications for pathname based mediation. The IPC and network mediation are a wip.

The fact that you have to go back to the drawing board for them is that you didn't get the abstraction right in the first place.

Quoted 2 lines · Lars Marowsky-Bree

And now, yes, I know AA doesn't mediate IPC or networking (yet), but that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based mediation doesn't generalize to cover all objects unlike label- or attribute-based mediation.

And the "use the natural abstraction for
each object type" approach likewise doesn't yield any general model or anything that you can analyze systematically for data flow.

Quoted 3 lines

If I restrict my Mozilla to not access my on-disk mail folder, it can't get there. (Barring bugs in programs which Mozilla is allowed to run unconfined, sure.)

Um, no. It might not be able to directly open files via that path, but showing that it can never read or write your mail is a rather different matter.

Quoted 3 lines

I believe AA breaks POSIX, already. rename() is not expected to change permissions on target, nor is link link. And yes, both of these make AA insecure.

AA is supposed to allow valid access patterns, so for non-buggy apps + policies, the rename will be fine and does not change the (observed) permissions.

Quoted 7 lines

Quoted 4 lines

If that is the only way to implement AA on top of SELinux - and so far, noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle, and for which there is demand.

What demand? SELinux is superior to AA, and there was very little demand for AA. Compare demand for reiser4 or suspend2 with demand for AA.

SELinux is superior to AA for a certain scenario of use cases; as we can see here, it is not superior to AA for _all_ use cases.

Quoted 6 lines

Quoted 2 lines

The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function

Which are exactly the bits Christoph Hellwig and Al Viro vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of VFS maintainer.

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

Quoted 3 lines

AA is supposed to allow valid access patterns, so for non-buggy apps + policies, the rename will be fine and does not change the (observed) permissions.

That still breaks POSIX, right? Hopefully it will not break any apps, but...

Quoted 2 lines

A veto is not a technical argument. All technical arguments (except for "path name is ugly, yuk yuk!") have been addressed, have they not?

There still is "it does not work with long pathnames".

Plus IIRC we have something like "AA has to allocate path-sized buffers along every syscall".

Quoted 3 lines · Pavel Machek

Plus IIRC we have something like "AA has to allocate path-sized buffers along every syscall".

That is an implementation bug though. I'm sure we have other bugs in the kernel too - this isn't a design flaw.

(If people are allowed to thinair solutions for implementing AA on top of SELinux, I can thinair that this can be solved by reverse-matching the dentry tree against the policy as the path is traversed and constructed, requiring a constant sized buffer.)

Quoted 4 lines

If that is the only way to implement AA on top of SELinux - and so far, noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle, and for which there is demand.

What demand? SELinux is superior to AA, and there was very little demand for AA. Compare demand for reiser4 or suspend2 with demand for AA.

Quoted 2 lines

The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function

Which are exactly the bits Christoph Hellwig and Al Viro vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of VFS maintainer.

well, if you _really_ want people who are interested in this to do weekly "why isn't it merged yet you $%#$%# developers" threads that can be arranged.

the people who want this have been trying to be patient and let the system work. if it takes people being pests to get something implemented it can be done, but I don't think other people on the list will appriciate this.

Quoted 7 lines

Quoted 2 lines

The code has improved, and continues to improve, to meet all the coding style feedback except the bits which are essential to AA's function

Which are exactly the bits Christoph Hellwig and Al Viro vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of VFS maintainer.

so you are saying that _any_ pathname based solution is not acceptable to the kernel, no matter what?

In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say "get it now, going away in 10 minutes" and then move it out again. Yes, you can manually address this by running "restorecon ~crispin/public_html". But AA does this automatically without having to run any commands.

Quoted 6 lines

In a smaller scale example, I want to share some files with a friend. I can't be bothered to set up a proper access control system, so I just mv the files to ~crispin/public_html/lookitme and in IRC say "get it now, going away in 10 minutes" and then move it out again. Yes, you can manually address this by running "restorecon ~crispin/public_html". But AA does this automatically without having to run any commands.

If you share ~crispin/public_html/lookitme by making a hard link, does relabeling approach work?
I thought SELinux allows only one label for one file.
If AA (on the top of SELinux) tries to allow different permissions to ~crispin/public_html/lookitme and its original location, either one of two pathnames won't be accessible as intended, will it?

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Quoted 3 lines

Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had".

Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct.

Quoted 4 lines

Pavel, please focus on the current AppArmor implementation. You're remembering a flaw with a previous version of AppArmor. The pathnames constructed with the current version of AppArmor are consistent and correct.

Ok, I did not know that this got fixed.

How do you do that? Hold a lock preventing renames for a whole time you walk from file to the root of filesystem?

A daemon using inotify can "instantly"[1] detect this and label the file properly if it shows up.

Same daemon can do the re-label.

Quoted 4 lines · Greg KH

A daemon using inotify can "instantly"[1] detect this and label the file properly if it shows up.

Same daemon can do the re-label.

Can the daemon using inotify access to all pathnames in all process's namespaces?

Are the namespace the daemon has and the namespace of pathnames notified via inotify always the same?

Quoted 2 lines · Tetsuo Handa

Can the daemon using inotify access to all pathnames in all process's namespaces?

I don't see why not, do you?

Quoted 2 lines

Are the namespace the daemon has and the namespace of pathnames notified via inotify always the same?

If they are in the same namespace, then yes, they will as far as I can tell. Do you think this is incorrect?

Quoted 5 lines · Stephen Smalley

- under AA, each file may have an arbitrary set of "labels" or "policies" applied to it depending on what programs are accessing it and what names are being used to reference it - there is no system view of the subjects and objects and thus no way to identify the overall system policy for a given file.

Look at it this way: under SELinux, the set of files that share a label forms an equivalence class -- they are all treated identically by the system's security policy. The rules in AppArmor profiles also define equivalence classes in the sense that they partition the filesystem namespace into sets of files that are treated identically, but this classification is not explicit -- the entire rule base contributes to the classification. This doesn't mean that there is not a global policy, just that the policy is modeled differently. The equivalence classes are not directly obvious from the AA profiles.

Contrast this with SEEdit, which compiles AA-style rules into labels (and thus equivalence classes). The resulting SELinux policy is a static snapshot that cannot easily accommodate rule base changes, is more limited with respect to new files (which would likely be fixable), and behaves differently in complex ways with file renames. What's more, most likely the compiled policy will be anywhere from very hard to impossible to analyze, so you pretty much lose on all ends.

Quoted 1 line

- names are far less tranquil than labels.

If I'm getting things right, a tranquil system with respect to labels would be one that does not permit re-labeling, while a tranquil system with respect to path names would be one that does not permit renaming. Both approaches would buy greater analyzability with reduced usability, and both seem unrealistic to me. SELinux and AppArmor evidently have different goals, and tranquility is more important to SELinux.

AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. SELinux is applicable in areas where AppArmor is not (e.g., MLS), but this comes at a cost. For me the question is not SELinux or AppArmor, but if AppArmor's security model is a good solution in common scenarios. In my opinion, AppArmor is a better answer than SELinux in a number of scenarios. This gives it value, nonwithstanding the fact that SELinux can be taken further.