Re: Preferred subj= with multiple LSMs

On 7/18/2019 8:01 AM, William Roberts wrote: 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.