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

[Casey Schaufler]

On 5/18/2020 5:16 PM, Casey Schaufler wrote:
> On 5/18/2020 3:21 PM, Paul Moore wrote:
>> On Mon, May 18, 2020 at 4:43 PM Casey Schaufler <casey at 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 at 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 at chromium.org>
>>>>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
>>>>> Cc: linux-audit at 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.
> That's not something that's coming from the kernel.

OK, I see that I missed one in netlbl_audit_start_common(),
although I don't think that's where this event came from.

> I'll check again, but I think that everyplace in the kernel that
> produces a subj= has been trained to create a type=1420 record
> instead.
>
>>>> 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.
> The CONFIG_CHANGE record already duplicates the subj= information
> in the SYSCALL record. I just maintained the duplication. You're
> right, it's silly to have two identical type=1420 records for the event.
> I will have to come up with a mechanism to prevent the duplication.
> with luck, there's already a similar case for some other record.
>
>> --
>> paul moore
>> www.paul-moore.com