On 11/01/2015 05:26 AM, intrigeri wrote: > Hi, > > I see that the user-tmp abstraction, included by many other profiles, > contains these rules: > > owner /var/tmp/** rwkl, > owner /tmp/** rwkl, > ^ > > Am I correct that on systems where /tmp and /var/tmp are on the root > filesystem, this essentially allows an attacker who took control of > a confined application to escape its AppArmor confinement, by creating > a hard link to any other place in the root filesystem, and that within > that filesystem it will then be only restricted by DAC? > > If I'm correct, then it sounds like it should be made clear, somehow, > that an operational requirement, for meaningful usage of upstream > profiles that include the user-tmp abstraction, is to have /tmp and > /var/tmp on dedicated filesystems. Is it the case already? > > (/me hopes he got something wrong.)
I am not a fan of those 2 rules, but its not quite as bad as that. Those rules are equivalent to owner /var/tmp/** rwk, owner /tmp/** rwk, owner link subset /var/tmp** -> /**, owner link subset /tmp/** -> /**, the subset restriction is the key and it means the target of link must have apparmor MAC permissions that are a subset of what is allowed of the link (and not just in the rule). So in this case, you can make a link to any file in the root file system as long as the profile allows at a minimum rwk permissions. You would not be allowed to create a hard link to a file you just have read permissions on. With that being said, cooperating tasks with different profiles could potentially leverage hard links to circumvent certain restrictions. We don't have a good solution for this yet, but the goal is to tighten this up. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
