[apparmor] [patch 14/XX] convert af_unix rules to support name= rather than path=

[Steve Beattie]

On Fri, Aug 22, 2014 at 01:17:41PM -0700, John Johansen wrote:
> On 08/22/2014 12:55 PM, Steve Beattie wrote:
> > This patch converts the path= modifier to the af_unix rules to use
> > name= instead. The reasoning here is that the audit log messages will
> > be using the keyword name instead of path, to be consistent with the
> > file log messages which report as name.
> > 
> > I'm... ambivalent about this patch, as the unix(7) documentation refers
> > to paths as well as netstat -x output. The file rejection logs are the
> > outlier here by referring to paths as names, but the keyword for them
> > doesn't get used in apparmor policy, unlike for the new unix socket
> > mediation. I think our options are:
> > 
> >   1) Take this patch and make the kernel rejection messages for af_unix
> >      refer to 'name', and accept the inconsistency with unix(7)
> >      documentation.
> > 
> we could
> 
> >   2) Keep using the path keyword in the userspace tools while leaving
> >      the logging consistent by using the name keyword there, and
> >      documenting the inconsistency between the log messages and the
> >      language.
> > 
> No
> 
> >   3) Use the path keyword in userspace and in af_unix log messages, and
> >      accept the inconsistency between af_unix and file log messages
> >      (with perhaps a long term plan to move the file log keyword to
> >      path).
> > 
> better
> 
> >   4) Keep the name keyword in the af_unix log messages to be consistent
> >      with file messages, but modify the parser to accept either the
> >      file= or path= keywords, as alternate ways of specifying the same
> >      thing, and accept the implementation complexity in the userspace
> >      tools, as well as potential user confusion over the keywords.
> > 
> not file= perhaps you meant name=

Yes, sorry; to clarify, we could modify the parser to accept either
name= or path= for af_unix rules, which would mean the same thing.

> So just to reiterate the abstract socket and file path name auditing
> take different paths. There is no need to have them be the same
> except for consistency in audit log naming.
> 
> However are we going to use name= for ipv4 and ipv6? Should the
> abstract address be more consistent with those?
> 
> laddr and faddr? For the auditing providing by lsm audit? Not that
> that really fits our logging either but ...

Are we planning to use the peer=(...) style that we've developed for
various IPC mechanisms for ipv4 and ipv6?

I like "name=" even less as a keyword for a local or remote network
address.

So I guess with the raised point about addresses, we could even extend
option 4 into option 4-ultra-waffle, where name=, path=, and addr=
(or address=) are all accepted as the path argument for unix rules.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140822/8c4ff41c/attachment-0001.pgp>