[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