On 08/22/2014 01:43 PM, Steve Beattie wrote: > 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 thought that was the whole point behind what we did there. We where trying to come up with something consistent, ...
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
