On Mon, May 18, 2020 at 4:43 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 5/18/2020 11:02 AM, Stephen Smalley wrote: > > On Thu, May 14, 2020 at 7:30 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> Create a new audit record type to contain the subject information > >> when there are multiple security modules that require such data. > >> This record is emitted before the other records for the event, but > >> is linked with the same timestamp and serial number. > >> > >> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > >> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > >> Cc: linux-audit@xxxxxxxxxx > >> --- > > With this patch, I see userspace audit records like this one: > > > > type=SYSTEM_BOOT msg=audit(1589816792.181:103): pid=789 uid=0 > > auid=4294967295 ses=4294967295 subj=? subj=system_u:system_r:init_t:s0 > > msg=' comm="systemd-update-utmp" > > exe="/usr/lib/systemd/systemd-update-utmp" hostname=? addr=? > > terminal=? res=success' > > > > I'm guessing that userspace is appending the second subj= field when > > it sees subj=? or otherwise is missing subj= information? > > I haven't looked at the userspace code, but I expect you're right. > It looks like there will need to be some change in the userspace > for the multiple LSM case. The "completion" shown here isn't correct, > because it only fills in one of the subject attributes, not both. Wait, didn't we agree on a a "subj=? subj_selinux=XXX subj_apparmor=YYY subj_smack=ZZZ" format? It looks like there are two 'subj' fields in the record above which is bad, don't do that please. > > Then we have kernel audit records like this: > > > > type=PROCTITLE msg=audit(1589816791.959:101): proctitle=2F7362696E2F617564697463 > > 746C002D52002F6574632F61756469742F61756469742E72756C6573 > > type=SYSCALL msg=audit(1589816791.959:101): arch=c000003e syscall=44 > > success=yes exit=1056 a0=3 a1=7fff9ccc98a0 a2=420 a3=0 items=0 > > ppid=773 pid=783 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="auditctl" > > exe="/usr/sbin/auditctl" subj=? key=(null) > > type=UNKNOWN[1420] msg=audit(1589816791.959:101): > > subj_selinux=system_u:system_r:unconfined_service_t:s0 > > subj_apparmor==unconfined > > type=CONFIG_CHANGE msg=audit(1589816791.959:101): auid=4294967295 > > ses=4294967295 subj=? op=add_rule key=(null) list=1 res=1 > > type=UNKNOWN[1420] msg=audit(1589816791.959:101): > > subj_selinux=system_u:system_r:unconfined_service_t:s0 > > subj_apparmor==unconfined > > > > where we are getting multiple copies of the new record type, one for > > each record type that had subj=?. > > While obviously wasteful, the type=1420 behavior is consistent with > the subj=? behavior, which is to duplicate the subj= value. I know > we've got enough hobgoblins in the audit system that we don't need > to add any more in the name of a foolish consistency. You need to provide a bit more reason why we need byte-for-byte duplicate records in a single event. As it currently stands this looks like something we definitely don't want. -- paul moore www.paul-moore.com
