On 2019/02/09 9:28, Tetsuo Handa wrote:
> On 2019/02/09 1:23, Casey Schaufler wrote:
>> On 2/8/2019 2:52 AM, Tetsuo Handa wrote:
>>> To help administrators easily understand what LSM modules are possibly enabled by default (which
>>> have to be fetched from e.g. /boot/config-`uname -r`)
>>
>> $ cat /sys/kernel/security/lsm
>>
>
> /sys/kernel/security/lsm is list of "actually" enabled modules, isn't it?
> What I want is "possibly" enabled modules. Ubuntu would chose from either
>
> (a) explicitly add security=apparmor to kernel command line
>
> or
>
> (b) explicitly remove tomoyo from CONFIG_LSM at kernel config
>
> in order not to enable TOMOYO for those who want to enable only one of
> SELinux/Smack/AppArmor. And for those who want to enable TOMOYO, I think
> that (b) (in other words, add
>
> lsm="modules listed in CONFIG_LSM" + ",tomoyo"
>
> ) will retain compatibility when it becomes possible to enable more than
> one of SELinux/Smack/AppArmor at the same time.
>
> If we can know "possibly" enabled modules from dmesg, users don't need to
> look at e.g. /boot/config-`uname -r`. It is not essential, but it's handy.
>
Well, thinking again, specifying
lsm="modules listed in /sys/kernel/security/lsm" + ",tomoyo"
makes sense, for there is no need to care about disabled modules when
enabling TOMOYO. Therefore,
+ pr_info("Security Framework initializing: %s\n", order);
- pr_info("Security Framework initializing\n");
won't be needed.
On 2019/02/09 6:33, Kees Cook wrote:
> On Thu, Feb 7, 2019 at 8:24 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>> I added Kees to the CC list. Kees, what to you think about
>> ignoring security= if lsm= is specified? I'm ambivalent.
>
> This was one of many earlier suggestions, and the consensus seemed to
> be "don't mix security= and lsm=". Why would anyone use both?
>
Then, can we add this change?
+ if (chosen_lsm_order) {
+ if (chosen_major_lsm) {
+ pr_info("security= is ignored because of lsm=\n");
+ chosen_major_lsm = NULL;
+ }
+ }
