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?
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
