On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@xxxxxxxxx> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> 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.)
>
> It doesn't, it needs to be specified in one place.
>
> Distros will need to update boot parameter handling for this kernel
> onwards. Otherwise, we will need to carry this confusing mess forward
> forever.
Are you saying that you want to overrule Paul and Stephen about
keeping "selinux=1 secuiryt=selinux" working?
>> 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?
>
> In my most recent suggestion, there is no '!' disablement, just
> enablement. If an LSM is not listed in CONFIG_LSM="", it's not enabled.
And a user would need to specify ALL lsms on the "lsm=" line?
What do you think of my latest proposal? It could happily work all
three ways: old boot params and security= work ("selinux=1
security=selinux" keeps working), individual LSM enable/disable works
("lsm=+loadpin"), and full LSM ordering works
("lsm=each,lsm,in,order,here"):
https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@xxxxxxxxxxxxxx/
-Kees
--
Kees Cook
Pixel Security
