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

[Jamie Strandboge]

On 08/22/2014 03:17 PM, 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 it worth noting that named-based unix(7) sockets use the 'file' perm and
are not covered by 'unix' rules, even though unix(7) covers them, anonymous and
abstract sockets. Also, the unix(7) man page refers to path, pathname, sun_path,
getsockname(2), getpeername(2), address, socket address. I think one could
support almost any position by referring to different parts of that page. :)

>> 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

I'm 'ok' with this. Note, the term 'path' is in the structure, but name also is
the 'name of the path', so I don't really think this is hideous. Note also that
getsockname(2) and getpeername(2) both have 'name' in the function name and
return the pathname (also note, 'pathname' has 'name' in the path too). This has
the main benefit of looking like file rules in the log (so name-based sockets
and abstract both use 'name='). There is some consistency there, but because you
have to use file or unix depending on the socket type, I'm not sure how much the
consistency is getting us.

> 
>>   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

I agree-- 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

I also agree here, better than '1', but not ideal when considering future
network rules.

>>   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=
> 
> 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 ...
> 

Since we are actually talking about abstract sockets and both the unix(7) man
page and the sun_path contains what the man page refers to as the socket address
*and* this address does not live in the filesystem (it just happens to look like
a filesystem path) *and* future consistency would be better served by making
these look like network, I think I most prefer 'addr' over 'name' or 'path'. We
therefore have:

unix addr="@/path",           # local abstract, log uses: addr="@/path"
unix peer=(addr="@/path"),    # peer abstract, log uses: peer_addr="@/path"
unix addr=none,               # local anonymous, log uses: addr=none
unix peer=(addr=none),        # peer anonymous, log uses: peer_addr=none

A future network syhntax could therefore be:
network addr=192.168.0.1,     # local address, log uses: laddr=192.168.0.1
network peer=(addr=10.0.0.1), # foreign address, log uses: faddr=10.0.0.1

Note, the network syntax is not finalized and AIUI we must use laddr and faddr
in the logs dur to lsm_audit.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140822/725ce61a/attachment.pgp>