Re: [PATCH v17 20/23] Audit: Add a new record for multiple subject LSM attributes

From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
	casey.schaufler@intel.com, James Morris <jmorris@namei.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	SElinux list <selinux@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	John Johansen <john.johansen@canonical.com>,
	penguin-kernel@i-love.sakura.ne.jp,
	Stephen Smalley <sds@tycho.nsa.gov>,
	linux-audit@redhat.com, Steve Grubb <sgrubb@redhat.com>,
	Richard Guy Briggs <rgb@redhat.com>
Subject: Re: [PATCH v17 20/23] Audit: Add a new record for multiple subject LSM attributes
Date: Mon, 18 May 2020 18:21:17 -0400	[thread overview]
Message-ID: <CAHC9VhRGopG0=DbEZArz2X2yfEQ1pOqoSLRMn9ABe5JYZB2Y8Q@mail.gmail.com> (raw)
In-Reply-To: <9cabbb54-69e6-91e6-88f8-e76d53da2a77@schaufler-ca.com>

On Mon, May 18, 2020 at 4:43 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 5/18/2020 11:02 AM, Stephen Smalley wrote:
> > On Thu, May 14, 2020 at 7:30 PM Casey Schaufler <casey@schaufler-ca.com> 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@chromium.org>
> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> >> Cc: linux-audit@redhat.com
> >> ---
> > 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