[apparmor] IPC syntax - again

John Johansen john.johansen at canonical.com
Fri Jul 5 21:29:20 UTC 2013


So a quick summary for people to mull over on weekend

1. Pairing vs. no pairing
   that is being able to tie mediation to both local and remote attributes
   at the same time. The attributes don't have to be addresses, however
   the subject labeling is implied (its the profile the rule is defined in).

   eg.  network tcp subject=(127.0.0.1:80) peer=(127.0.0.1)

2. Separation of Remote vs. Local address
   If pairing is not used do we identify/separate what is a local or remote
   address. If we don't we treat everything as a shared object (think file),
   which works but may be confusing in some situations

   eg.
      network bind inet 127.0.0.1:80,
      network (send, receive) inet 80.9.6.12,
      vs.
      network (send, receive) inet  peer=(80.9.6.12),

3. Whether local only permissions should be split from other permissions.
   ie. whether bind should have to appear in a different rule than
   send, receive as was done in the above example.

   3.1 variant suggested of one permission per rule. This breaks with the
       existing permissions for files, mount, ...

4. Where permissions should appear in the rule.

   tail:
      network inet peer=(80.9.6.12)  (send, receive),

   embedded:
      network inet (bind) subject=(127.0.0.1:80) (send, receive) peer=(80.9.6.12),  # or what ever the exact syntax was /me didn't care enough to look back in the discussion

   after keyword: the question of which keyword arises
      network (send, receive) inet peer=(80.9.6.12),
      vs.
      network inet (send, receive)  peer=(80.9.6.12),

     remember dbus especially af_dbus (I know not being merged) could be
     thought of as network
      dbus (send, receive) address=foo.com,
      vs.
      network (send, receive) dbus address=foo.com,
      vs.
      network dbus (send, receive) dbus address=foo.com,

   front:
      (send, receive) network inet peer=(80.9.6.12),


   Of particular importance in this decision are pure label rules that
   don't specify a type of communication.
      label=foo  rw,
      rw label=foo,

   there is no keyword to put the permission after.


5. Should we allow for permission aliases?
   send, receive for read, write
   acquire for bind

   Sometimes one form is more natural than the other


6. format of identifying local and remote addresses, it appears that
   peer=( ) was settled on and that subject=( ) was preferred over local=( )




More information about the AppArmor mailing list