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

From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: John Johansen <john.johansen@canonical.com>,
	SElinux list <selinux@vger.kernel.org>,
	Richard Guy Briggs <rgb@redhat.com>,
	James Morris <jmorris@namei.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	linux-audit@redhat.com, casey.schaufler@intel.com,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH v17 20/23] Audit: Add a new record for multiple subject LSM attributes
Date: Mon, 18 May 2020 13:42:58 -0700	[thread overview]
Message-ID: <9cabbb54-69e6-91e6-88f8-e76d53da2a77@schaufler-ca.com> (raw)
In-Reply-To: <CAEjxPJ67cA_A-Oh72EGgmCrP6k9x0PuaU2q7UL9eOc+J6Do0zQ@mail.gmail.com>

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.

> 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.

> Not sure what it is the audit folks want here.

I doubt that redundant type=1420 records are a good idea, but having
seen some of the other active threads about useless fields I am not
going to assume what is most appropriate.

> This is with multiple LSMs enabled; need to confirm that no change
> occurs if only one is enabled.

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit