Richard Guy Briggs <rgb@xxxxxxxxxx> writes: > 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 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. Eric > <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
