Preferred subj= with multiple LSMs

[Casey Schaufler]

On 7/18/2019 8:01 AM, William Roberts wrote:
> <snip>
>
>>>>>>> the following (something between option #2 and #3):
>>>>>>>   subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux
>>>>>>>
>>>>>>> subj2=<selinux_label> ...
>>>>>> If it's not a subj= field why use the indirection?
>>>>>>
>>>>>>         subj_smack=<smack_label> subj_selinux=<selinux_label>
> FWIW +1 on this approach.

Stephen Smalley's original objection was that subj=<context> used
the context from the "display" LSM, and that unprivileged users could
change that. Paul Moore suggested using subj=? and supplying additional
subject data at the end of the record, using what has evolved into the
subj_<lsm>=<context> format. Steve Grubb points out that searching on
subject contexts gets much harder using this scheme.

If instead of using "subj=?" we provide the context used when "display"
is not specified, subj=a:b:c:d when the first registered "display" LSM
in SELinux, and add the subj_<lsm>=<context> entries, we have a reasonably
good chance of getting the right results.

User-space code that does not understand that there may be multiple
contexts will get a consistent set of values. They will either be all
right or all wrong. The irreverent side of me thinks this could be an
interesting fuzz test case.

It will be simple to change applications that only work with one LSM
to check if they can expect data to be from that LSM in the audit records
by reading /sys/kernel/security/lsm to get the stacking order. That
can be done in a wrapper script.

A script could easily replace the subj= value from an LSM you don't want
with the subj_<lsm>= value that you do want:

sed -e 's/\(.*\) subj=[^ ]*\(.*\) subj_apparmor=\([^ ]*\)\(.*\)/\1 subj=\2 \3/

isn't quite right, but isn't far off.

Applications that are truly stack aware can use the subj_<lsm>=<context> values. 

On a "well configured" system (e.g. out of box Fedora or Ubuntu)
everything continues to work properly.

If AppArmor is added to the Fedora system, in the module list after
SELinux, and any applications that are dealing with AppArmor
understand they aren't "display"ed, it will continue to work.

This also works for Ubuntu, where SELinux would be put after AppArmor,
and SELinux applications would have to know they're not "display"ed.

I'm ignoring applications like id(1) that make explicit checks for a
particular LSM rather than handling the general case, and systemd or dbus,
which extend kernel policy into user-space. The topic at hand is audit,
so let's restrict the discussion to that for the moment.