[apparmor] Handling expanded permissions
John Johansen
john.johansen at canonical.com
Fri Jul 30 00:51:20 BST 2010
For a long time AppArmor has limited it self to a small permission set that is
fairly easy to understand. However sometimes it is inadequate for specific
policy goals.
The new AppArmor code provides a greatly expanded set of permissions, mapping
the existing permissions to multiple internal permissions.
r => data-read, meta-read, dac-override+*, dac-readsearch?
w => append, create, delete, data-write, meta-write, chmod, trunc+, chown*, sticky?, setuid? setguid?
+ currently implicit but could be made explicit if there is an adequate reason
* requires the capability as well
? not currently possible to handle well at a per path level, but could possibly be
in the future. If desirable, but can also be at least partially covered by
extended capabilities.
eg.
owner=(jj, smb) capability dac-override
Going forward we are going to want ways to express these permissions in policies.
Some of them might lend themselves to single character representations,
create c, delete d
others are probably better expressed by name, eg.
chmod /foo/bar,
which while it looks like its own rule can be flipped as standard permissions can
/foo/bar chmod,
chown in particular seems to be asking for its own rule as you want to be able to
do fine grained ownership.
chown /foo/bar to (jj,smb)
owner chown /foo/bar to (jj,smb)
owner=(fred, george) chown /foo/bar to (jj,smb)
it also requires some interaction with capabilities that can be sorted out in
a separate mail.
another possible extension includes allowing doing permission subtraction, so not
all permissions need to be enumerated when something other than the base permission
is given
/foo w - create,
instead of
/foo append delete data-write meta-write chmod trunc chown,
so opinions, ideas, alternatives?
More information about the AppArmor
mailing list