[lkml]   [2007]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Sat, 9 Jun 2007, Sean wrote:

>> the AA policy is also much easier to understand becouse you can look at it
>> in pieces, understand that piece, and then forget it and move on to the
>> next piece.
> Nobody is asking you to change the AA policy file. It lives in user space.
> But i fail to see the problem in translating it into SELinux terms for
> the user transparently.

>> for example, if you write a policy for apache that limits it's access to
>> it's log files, install directories, and document root. then you write a
>> policy for your log analysis tool to access it's libraries, report
>> directories (under the apache document root) and the apache log files
>> (read only), these two policies are independant, you don't have to think
>> about one while creating the other (which you would have to do if you had
>> to put one label on apache binaries, another on normal web documents, a
>> third on the reports, a fourth on the log files, and a fifth on the
>> binaries for the log analysis tool. and this is ignoring any overlap in
>> libraries!)
> Again, try to think outside the box a bit. This isn't about using SELinux
> as it exists today. But imagine an SELinux that would ask you to
> supply a security label for each file _instead_ of looking up that label
> itself. Wouldn't that let you implement everything you wanted while still
> using much of the SELinux infrastructure that is already in the kernel?

so are you suggesting that SELinux would call out to userspace for every
file open to get the label for that file?

just off the top of my head

what would all these kernel->userspace->kernel transitions do to

would SELinux give userspace the full path to that file?

if so wouldn't it have to implement most of what AA adds to do this?

if not how would userspace figure out what label to hand back without this

how would SELinux figure out the permissions for the userspace Daemon?

how would you change both the rules for labels in the kernel and the
policy for assigning labels in userspace without any race conditions?

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

yes, you could add all the AA code to SELinux and then say that the result
is implemented in SELinux, you may even save a little bit of code in some
parts of it (but I would argue that you add more code in others, say for
the userpace interface and userspace labeling code), but the result
wouldn't be in the spirit of SELinux.

it may be possible to write something that resembles AA in SELinux policy
(once you solve the problem of how to label newly created files securely),
but it's also possible to write a webserver in COBOL to run out of inetd,
that doesn't mean that it makes any sort of sense to do either one.

on the other hand, it may be a good idea. let's see how people really use
AA once they have it available and the SELinux folks can work on
duplicating the functionality, if they do then the existing AA interface
could be phased out over time, or the internal implementation could
change. but arguing that SELinux _may_ be able to do the job of AA
_someday_ should not prevent AA from being included today (especially when
so many of the SELinux developers are so opposed to the very concept of
AA, which doesn't indicate that they are about to rush out and implement
the pieces needed to make it work)

David Lang

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-06-09 07:43    [from the cache]
©2003-2011 Jasper Spaans