On Thu, Sep 13, 2018 at 5:08 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 9/13/2018 4:57 PM, Kees Cook wrote: >> On Thu, Sep 13, 2018 at 4:51 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>> On 9/13/2018 4:06 PM, Kees Cook wrote: >>>> - what order should any stacking happen? Makefile? security=? >>> Makefile by default. >> Okay, if ordering is by Makefile and everyone dislikes my >> $lsm.enabled=0/1 thing, then these mean the same thing: >> >> security=selinux,tomoyo >> security=tomoyo,selinux >> >> i.e. order of security= is _ignored_ in favor of the Makefile ordering. > > No, I think that the two lines above should have a different > execution order. If we really need to specify multiple modules > at boot time that is what makes the most sense. > > It's a matter of mechanics and probably another pass during the > init process, but it's doable. If we determine it's necessary for > this stage it is just work. We already have the minor LSMs that cannot change order. They aren't part of security= parsing either. To enable/disable LoadPin, you do "loadpin.enabled=1/0" separate from "security=". Should "blob-sharing" LSMs be like major LSMs or minor LSMs? If someone is booting with "security=selinux,tomoyo" and then SARA lands upstream, does that person have to explicitly add "sara" to their boot args, since they're doing a non-default list of LSMs? (I actually prefer the answer being "yes" here, FWIW, I just want to nail down the expectations.) -Kees -- Kees Cook Pixel Security
