[apparmor] user-tmp abstraction, hard links, and separate filesystems

[John Johansen]

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.