On 10/03/2018 04:59 PM, Randy Dunlap wrote: > On 10/3/18 4:55 PM, Kees Cook wrote: >> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@xxxxxxxxx> wrote: >>> On Wed, 3 Oct 2018, Kees Cook wrote: >>> >>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@xxxxxxxxx> wrote: >>>>> On Wed, 3 Oct 2018, Kees Cook wrote: >>>>> >>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@xxxxxxxxx> wrote: >>>>>>> On Tue, 2 Oct 2018, John Johansen wrote: >>>>>>>> To me a list like >>>>>>>> lsm.enable=X,Y,Z >>>>>>> >>>>>>> What about even simpler: >>>>>>> >>>>>>> lsm=selinux,!apparmor,yama >>>>>> >>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot >>>>>> separator (this makes it more like module parameters, too). You want >>>>>> to mix enable/disable in the same string? That implies you'd want >>>>>> implicit enabling (i.e. it complements the builtin enabling), which is >>>>>> opposite from what John wanted. >>>>>> >>>>> >>>>> Why can't this be the order as well? >>>> >>>> That was covered extensively in the earlier threads. It boils down to >>>> making sure we do not create a pattern of leaving LSMs disabled by >>>> default when they are added to the kernel. The v1 series used >>>> security= like this: >>>> >>>> + security= [SECURITY] An ordered comma-separated list of >>>> + security modules to attempt to enable at boot. If >>>> + this boot parameter is not specified, only the >>>> + security modules asking for initialization will be >>>> + enabled (see CONFIG_DEFAULT_SECURITY). Duplicate >>>> + or invalid security modules will be ignored. The >>>> + capability module is always loaded first, without >>>> + regard to this parameter. >>>> >>>> This meant booting "security=apparmor" would disable all the other >>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to >>>> leave it to only select the "major" LSM: all major LSMs not matching >>>> "security=" would be disabled). So I proposed "lsm.order=" to specify >>>> the order things were going to be initialized in, but to avoid kernels >>>> booting with newly added LSMs forced-off due to not being listed in >>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs. >>>> (i.e. anything missing from lsm.order would then follow their order in >>>> CONFIG_LSM_ORDER, and anything missing there would fall back to >>>> link-time ordering.) However, then the objection was raised that this >>>> didn't provide a way to explicitly disable an LSM. So I proposed >>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over >>>> CONFIG_LSM_DISABLE. >>> >>> Ok, but it may end up being clearer, simpler, and thus more secure to just >>> have a single way to configure LSM. >>> >>> For example: >>> >>> - All LSMs which are built are NOT enabled by default >>> >>> - You specify enablement and order via a Kconfig: >>> >>> CONFIG_LSM="selinux,yama" >>> >>> - This can be entirely overridden by a boot param: >>> >>> lsm="apparmor,landlock" >> >> This doesn't work with how SELinux and AppArmor do their bootparams, >> unfortunately. (And Paul and Stephen have expressed that the >> documented selinux on/off must continue to work.) For example, let's >> say you've built an Ubuntu kernel with: >> >> CONFIG_SELINUX=y >> ... >> CONFIG_LSM="yama,apparmor" >> >> (i.e. you want SELinux available, but not enabled, so it's left out of >> CONFIG_LSM) >> >> Then someone boots the system with: >> >> selinux=1 security=selinux >> >> In what order does selinux get initialized relative to yama? >> (apparmor, flagged as a "legacy major", would have been disabled by >> the "security=" not matching it.) >> > > To me, "security=selinux" means SELinux and nothing else, so I think that > all of these params are inviting a lot of confusion. > > Sorry, I don't have a good answer for this. > Your not the only one. I have had users ask about why they are getting other security messures (yama in particular) when they specified a specific security= >> >> The LSM order needs to be defined externally to enablement because >> something may become enabled when not listed in the order. >> >> Now, maybe I misunderstood your earlier suggestion, and what you meant >> was to do something like: >> >> CONFIG_LSM="yama,apparmor,!selinux" >> >> to mean "put selinux here in the order, but don't enable it". Then the >> problem becomes what happens to an LSM that has been built in but not >> listed in CONFIG_LSM? >> >> Related to that, this means that when new LSMs are added, they will >> need to be added to any custom CONFIG_LSM= or lsm= parameters. If >> that's really how we have to go, I'll accept it, but I think it's a >> bit unfriendly. :P >> >> Another reason I don't like it is because it requires users to know >> about all the LSMs to make changes. One LSM can't be added/removed >> without specifying ALL of the LSMs. (i.e. there is no trivial way to >> enable/disable a single LSM without it growing its own enable/disable >> code as in SELinux/AppArmor. I'd hoped to make that easier for both >> users and developers.) Again, I can live with it, but I think it's >> unfriendly. >> >> I just want to have a direct I can go that meets all the requirements. >> :) I'm fine to ignore my sense of aesthetics if everyone can agree on >> the code. > >
