On 14/05/20, Richard Guy Briggs wrote: > On 14/05/20, Eric Paris wrote: > > On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: > > > The purpose is to track namespaces in use by logged processes from the > > > perspective of init_*_ns. (Including the Linux API list due to the additions to /proc/<pid>/ns/. Please see http://www.kernelhub.org/?p=2&msg=477668 and in particular http://www.kernelhub.org/?msg=477678&p=2 ) <snip> > > > 5/6 provides an example of usage for audit_log_task_info() which is used by > > > syscall audits, among others. audit_log_task() and audit_common_recv_message() > > > would be other potential use cases. > > > > > > Proposed output format: > > > This differs slightly from Aristeu's patch because of the label conflict with > > > "pid=" due to including it in existing records rather than it being a seperate > > > record. The serial numbers are printed in hex. > > > type=SYSCALL msg=audit(1399651071.433:72): arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=ffffffffffffffff a2=0 a3=22 items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5 subj=system_u:system_r:init_t:s0 key=(null) > > > > I'm undecided if I'd rather see this as a separate NS_INFO record type. > > It would mean we could filter them out of the logs... > > I don't have a strong opinion either way. Steve G.'s opinion would be > helpful here. Breaking this out into a seperate record type would mean calling audit_log_namespace_info() from the callers of audit_log_task_info() (presently audit_log_link_denied(), ima_audit_measurement(), audit_log_exit() ), but would make it easier to emit with other record types. > > Do we print out lots of pidns=0 for tasks not in a newly created NS? Do > > we want to? > > There is no "pidns=0", but I understand your point. This would come > back to Steve G.'s point about disappearing fields, and the value of > having it as a seperate record that could be filtered. > > > > 6/6 tracks the creation and deletion of of namespaces, listing the type of > > > namespace instance, related namespace id if there is one and the newly minted > > > serial number. > > > > > > Proposed output format: > > > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=20000 old_snum=0 snum=a1 res=1 > > > > I'd love to be able to grep for netns=20 and find both the NS_INIT and > > the SYSCALL/NS_INFO records, instead of having them named different > > things. So basically I think you want to translate the type= into a > > string for the old_X= and X=... > > That actually makes a bit more sense, and we could do away with the > "type=" field since the "Xns=" fields are self-describing. Steve, how do you feel about this since the NS_INIT/NS_DEL record type would have changing fields amongst the 6 namespace types. Only one of the 6 would be present in each message. I suppose we could have an NS_INIT_XXX/NS_DEL_XXX for each namespace type. > - RGB - RGB -- Richard Guy Briggs <rbriggs@xxxxxxxxxx> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
