[apparmor] Improving policy abstractions

[John Johansen]

On 08/18/2010 04:00 PM, Christian Boltz wrote:
> 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. 
> 
currently they are, but that doesn't really solve the problem.
The tools will suggest an abstraction and it may have a wider set of
privileges than needed.

> 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
that does help carry meaning

> - if write access is optional, split the abstractions to foo and 
>   foo_write. foo_write should #include foo.
> 
right.

> Maybe the policy isn't that easy to define, but you should get my point.
> 
> IMHO a technical solution with new syntax is overkill.
> 
hrmm maybe, the goal is to find the best way forward and we are open
to all suggestions

>> #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 ;-)
> 
yes we need to split abstraction more, any way we do it.  And the tools
should suggest minimum privileges first.

>> 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...
> 
right this isn't actually what I was thinking of.  Masking is the road
to madness.

Instead it was here is a list of related things, now stick permissions
on them as needed.  Splitting out and renaming the includes may be 
sufficient


> 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]
> 
hehe yes lets try to make things clearer.  btw lol catz policy is off
limits to
http://userweb.kernel.org/~jmorris/lss2010_slides/lolpolicy.pptx

>>  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.
> 
Its not so much wanting a new feature as finding the current abstractions
insufficient and looking for something better.

> 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?
> 
well, think rbac a one user may have admin privileges for log files
another just read access.  Or perhaps the rights to create a file if it
doesn't exist.

Think of a java being started from a web browser with fewer permissions
than you might for a java application started locally.

The goal is to better group minim sets of resources.  One way to do that
is to separate those resource lists, and permissions.  Another is what
you suggested above, of breaking up includes by resource list and 
permissions, which might be the better solution.

> 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.
> 
well for to reasons, I often think of the terms of type enforcement 
(apparmor is not actually that far removed and its the best way to do
total policy analysis) so it is a natural fit for me, and two I would
like to offer access to group information, for conditional rules.

But you are right most people would think of it more as a group or list.

thanks for the input Christian