[apparmor] [PATCH v2] apparmor: implement profile-based query interface in apparmorfs

[Seth Arnold]

On Tue, Mar 05, 2013 at 11:20:35PM -0800, John Johansen wrote:
> > I was initially uneasy about giving it 0666 perms, but I don't see a way
> > around it.
> > 
> well we can do something with in apparmor itself so, some additional check
> beyond 0666. I agree unprivileged apps need to work with it, but we could
> do things like limit queries against their own confinement, or subset
> of their confinement, and/or add an apparmor "capability" controlling
> the ability to query policy.

It's funny, the first time I read the '666' mode, I was pretty happy
to see that it wouldn't require giving extra privileges to programs
that wanted to use AppArmor policy to enforce some portion of their own
security policy.

CAP_MAC_ADMIN seems like the exact wrong direction to go -- I certainly
don't want e.g. the dbus daemon to have this capability[1]. CAP_MAC_QUERY
or a similar new capability would be fine -- even an AppArmor specific
"capability", though that might introduce the need to write a profile
for an application that wouldn't otherwise need one.

But it's difficult for me to imagine a program that enforces some amount
of access control over its resources -- and can't itself be confined. So
it feels safe to grant access only via policies.

Of course, controlling what is queried sounds like a reasonable thing
to write in an AppArmor profile... (What a coincidence! We have a DFA
language to encode permissions!) 

Is it worth it though? Is it _so_ important to keep dbus from learning
about the policy being enforced in a database on the system?

1: What do we do about CAP_AUDIT_WRITE? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130306/eab12dbe/attachment.pgp>