[apparmor] Improving policy abstractions
apparmor at cboltz.de
Thu Aug 19 00:00:47 BST 2010
Am Dienstag, 10. August 2010 schrieb Seth Arnold:
> Now that I don't know the abstractions as well as I used to (thanks
> Jamie! :) I find myself wondering just what permissions are being
> Specifically, I have wanted something like:
> #include (authentication, read)
> To make sure I'm not accidentally granting write access to my auth
All abstractions/* files are hand-written (as in: the tools don't edit
them). This means that there should be nothing that "accidently" grants
IMHO the problem can be solved by policy ;-)
A simple proposal I thought about:
- abstractions should in general not contain write access with the
- sockets that are obviously required (like /var/lib/mysql.sock for
- very basic functions like /dev/null and /dev/log
(in other words: abstractions/base)
- if an abstraction provides write access, it has to be named "*write",
or even "*_write_xyz", for example abstractions/authentification_write
- if write access is optional, split the abstractions to foo and
foo_write. foo_write should #include foo.
Maybe the policy isn't that easy to define, but you should get my point.
IMHO a technical solution with new syntax is overkill.
> #include (authentication, files)
> So I don't wind up supporting a dozen different auth tools I don't
In other words: you want to split abstractions/foo into
abstractions/foo_authentification and foo/files ;-)
> Of course, I'm scared of parameterized policy, it runs the very real
> risk of growing into a hydra,
Exactly. This is one reason why I don't like the idea of "partly
The other reason is that it would make it much harder to tell which
parts of an included file actually apply - for both the parser and (IMHO
more problematic) for humans reading a profile.
#include (readonly) <abstractions/foo>
would mean you have to ignore all "w" flags while reading
I already need Aspirin for XSLT. I don't want to need it for AppArmor
In other words:
That would be very confusing. (Un?)fortunately confusion is a registered
trademark of SElinux, so AppArmor is not allowed to cause it ;-) 
> perhaps your idea of further
> constraining it into types makes sense. (And types would be neat for
> networking and probably IPC too.)
If you really want a new feature ;-) then this sounds like the better
idea. It looks more flexible to me and is easier to parse for humans.
However, I don't see a real-world usecase where (parts of) an
abstraction file should have different permissions in some use cases.
Can you give some examples, please?
A final small question: why do you call this "type" and not "group"?
"group" sounds like a better description to me, and AFAIK "group" is not
yet used as keyword.
 credits for this go to Eberhard Moenkeberg, see sig...
Non-understandable error messages are trademark of someone else, so
SUSE is not allowed to submit them. ;-)) [Eberhard Moenkeberg in
More information about the AppArmor