[apparmor] Improving policy abstractions

[Christian Boltz]

Hello,

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
>  granted.
> 
> Specifically, I have wanted something like:
> 
> #include (authentication, read)
> 
> To make sure I'm not accidentally granting write access to my auth
>  databases.

All abstractions/* files are hand-written (as in: the tools don't edit 
them). This means that there should be nothing that "accidently" grants 
permissions. 

IMHO the problem can be solved by policy ;-)

A simple proposal I thought about:
- abstractions should in general not contain write access with the
  exception of 
  - sockets that are obviously required (like /var/lib/mysql.sock for 
    abstractions/mysql)
  - 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
  or abstractions/authentification_write_passwd
- 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
>  have.

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 
include".

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.

Simple example:
    #include (readonly) <abstractions/foo>
would mean you have to ignore all "w" flags while reading 
abstractions/foo. 
I already need Aspirin for XSLT. I don't want to need it for AppArmor 
profiles also...

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 ;-)   [1]

>  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.


Regards,

Christian Boltz

[1] 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
https://bugzilla.novell.com/show_bug.cgi?id=209354]