[apparmor] Recursive permission tagging
John Johansen
john.johansen at canonical.com
Sat Aug 14 00:06:35 BST 2010
I have been looking at how to handle btrfs snapshotting, which can be
thought of as a super powerful hardlink to a directory (btrfs is more
nuanced but treating it as a directory will work for the purpose of the
discussion).
The snap shot, retains all the inodes, permission etc, of every
item within the tree. From a named base security perspective it creates
name aliases for everything in the tree which can be used to circumvent
policy.
This situation is actually very similar to moving a directory, except
that the directory move doesn't create a new alias for every directory
and file in the tree.
To deal with such operations, the intuitive solution is that the
confining profile will need permissions on the whole tree being moved
(or snapshotted) and at the target.
eg. For a program to move /a/ to /b/ its profile would require
/a/ rw,
/a/** rw,
/b/ rw,
/b/** rw,
This would be the minimum permission set for a move, in the case
of a snapshot
/a/ rl,
/a/** rl,
/b/ rw,
/b/** r,
This permission condition is actually easy enough to detect with the
dfa, and could be efficiently computed. However what it does not take
into account is DAC.
If a process does not have DAC override should it be capable, of making
such a snapshot, or move. DAC will still be enforced so this will not
allow any extra access permissions.
The question becomes even harder when the rules in the profile are
conditional on ownership. Ie.
owner /a/ rw,
owner /a/** rw,
To enforce this the kernel either needs to examine every file in the
tree (NOT going to happen), or have a userspace helper to do the test
(possible).
In general I think we should currently aim to support the generic
permission case, and then we can look at the conditional permission
cases. Later.
More information about the AppArmor
mailing list