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 <[email protected]> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
