On 03/06/2013 05:35 PM, Seth Arnold wrote: > 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. Well its not so much about enforcing their own security policy as a trusted helper (dbus) enforcing policy that the kernel doesn't have the correct scope for.
> > 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 agreed > 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. > unconfined would remain unconfined, at least to a certain degree, there are already differences between an unconfined user app and unconfined app with admin capabilities. Some of those style of restrictions could be added here (eg possibly uid checks + falling back to needing a capability). An apparmor "capability" would be a capability that would only need to be listed in profiled applications that wanted to do the querying. We aren't extending the system caps, unless there is a generic capability that other LSMs could use. And unconfined wouldn't need a profile just to do access checks. > 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. > Heh there are certainly advantages to confining a trusted application, but its not required. Its enforcing policy on other confined apps and as long as it doesn't have a flaw that can be exploited it doesn't necessarily have to be confined. Confine it does however have the advantage of controlling what it can do and also providing a label beyond the generic unconfined which is beneficial for policy describing the interaction between domains. > 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!) > yes and its flexible and extensible, what fun > 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? > It not the dbus that I am worried about, its any old application, say an apache service using mod_changehat, that is broken and can now query the system not just for its confinement but all policy > 1: What do we do about CAP_AUDIT_WRITE? > We require capability audit_write in the profile if the tasks does anything requiring that capability. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
