On 05/29/2015 09:29 AM, Simon McVittie wrote: Hey Simon, thanks for the excellent mail, sorry for the delay in reply we have been busy
> On 28/05/15 11:14, John Johansen wrote: >> With reducing this to a single blob of data I think we could consider >> having a more generic command, to just ask for a named blob of data. >> This way the command isn't dconf specific but could serve dconf and >> maybe other uses in the future. > yes, apparmor does in fact have a more general command, I will explain more below. This specific case is extending information contained in policy, and again we would like it to be something that is generic and can be leveraged by other services, like polkit or ubuntu touch file picker. The dconf case is that it wants something more than what we currently easily allow from policy. Currently our policy allows for very generic queries and policy but it is quite difficult to pull information out of it that is not a direct permission query. The specific information being sought here is a set of dconf paths to set watches on. It would be possible to extract this from the dfa/hfa but that really isn't the best approach, as it is easier to build this list during the policy compile. So what I would like to see here from the kernel is a generic mechanism to supply ancillary information, beyond what is allowed by current policy, for a given class. It is then up to the class to interpret the blob. Currently policy allows defining a class, and then class is responsible for defining and interpreting the data within that class. So it is possible for userspace agents (if you look at any of the ubuntu apparmor documents they are called trusted helpers) to define a policy that will work for what they are trying to achieve. Those agents can then query policy, and do their enforcement based off of it. The limitation is that this policy gets compiled into the minimized dfa/hfa matching engine, which is great for what it is designed for but falls short for other things. > One concrete thing that might benefit from a more generic approach to > user-space mediation is polkit (formerly PolicyKit). You probably all > know how polkit works and how it interacts with AppArmor, but in case > anyone reading this doesn't, here is a summary. > > The ideal situation for AppArmor is when a process does a > "controversial" operation, e.g. mounting a disk, directly (a direct > request to the kernel), in which case AppArmor code in the kernel can > mediate the operation in the obvious way. This is fine for actions that > would be allowed by DAC and are only being denied by MAC, like writing > to an owned file; but not so good for actions that DAC would deny > anyway, like mounting disks. > > However, many processes on a modern system do operations by submitting > an IPC request to a more-privileged service which will do the actual > operation: for instance, desktop environments don't mount USB drives, > they ask udisks2 to mount USB drives for them. In these cases, the > kernel's normal DAC permissions checks and AppArmor checks are not > particularly useful: they only determine whether the process can > talk to the service at all. Some applications have absolutely no > legitimate reason to talk to udisks2, so AppArmor rules can just block > it altogether; but this is rather coarse-grained, and does not allow > (for instance) inspecting filesystems' types but not mounting them. > > For the specific case where the IPC is via D-Bus, we do have > fine-grained checks on the header part of the D-Bus message. However, > those checks are not particularly useful, because neither AppArmor nor > dbus-daemon really understands what is happening. For instance, we can't > know whether a call to org.freedesktop.UDisks2.Filesystem.Mount() is > acting on a USB drive (in which case it's probably OK) or on an > internal/system drive (in which case it probably isn't). This is where > components like freedesktop.org's polkit (and Tizen's Cynara, which > competes directly with polkit) come in. > > Another factor here is that the authors of kdbus strongly oppose > applying in-kernel controls to kdbus messages that parse the message's > payload (the body, and all parts of the traditional D-Bus header not > used for routing, i.e. everything except the source and destination), on > the basis that the interpretation of the payload is entirely up to the > recipient anyway; so these fine-grained checks are not going to be > available on kdbus, unless AppArmor incorporates a strictly > validating[1] GVariant parser into the kernel (in practice this seems > unlikely). > yes and no. The AppArmor kernel wouldn't, but it would be possible to by specifying it within the policy match engine (well at least with a little more work). The policy can be fully validated, and minimized and this is then loaded into the kernel and enforced. But that isn't to say we will be doing it, in the case of kdbus it would require patching the kernel to get the payload into the lsm. > The service to which the operation was delegated understands more about > the context and high-level meaning of the request than generic > infrastructure like AppArmor and dbus-daemon can: for instance, udisks2 > understands the domain-specific difference between mounting a USB drive, > which is potentially OK, and altering the root filesystem's mount > options, which is dangerous and shouldn't be allowed. This means it can > do a finer-grained check, taking into account the high-level meaning of > what is being done. Because the service understands the request, the > question it asks when checking a policy can be a lot more specific: for > instance, for USB storage, instead of asking "is this process allowed to > mount filesystems?" (which would, in general, be dangerous, so we would > have to say no), it can ask "is this process allowed to mount removable > disks with sane options?" (which is a special case, and is OK to allow). > yep > In the case of polkit, the approach that services are encouraged to take > is to use the polkit client library to call out to the polkit daemon, > specifying an abstract "action" like > org.freedesktop.udisks2.modify-device-system or > org.freedesktop.udisks2.modify-device-other-seat; the definition of the > action has a default policy designed to be reasonable in most cases, and > sysadmins can override that policy to impose their preferred local > security policy. Because these actions are defined by the service, which > knows about the specifics of the problem it solves, they can take into > account any domain-specific distinctions that the service author thinks > are likely to be interesting to a security policy author. > yep > At the moment, the polkit daemon bases its policy on the uid and pid of > the requesting process (usually determined by the service using > dbus-daemon's APIs). On dbus 1.9+, it could use > GetConnectionCredentials() to receive the uid, pid and LSM context > simultaneously, after which it could do an AppArmor query in much the > same way that dbus-daemon does. > yep > Here's a sketch of how this could look, for instance: > > audit polkit action=org.freedesktop.udisks2.filesystem-mount, > audit deny polkit \ > action=org.freedesktop.udisks2.filesystem-mount-system, > > or if the syntax in policy files was entirely generic, perhaps something > more like: > > userspace class=polkit \ > action=org.freedesktop.udisks2.filesystem-mount, > audit deny userspace class=polkit \ > action=org.freedesktop.udisks2.filesystem-mount-system, > > Does this sound like a reasonable generalization? > generally speaking, yes :) I can't say when polkit will get patched but I expect it will happen sooner than later. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
