Re: LSM stacking in next for 6.1?

[John Johansen <john.johansen@canonical.com>]

On 9/14/22 06:57, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>>
>> The community that is absolutely opposed to loadable modules will disagree.
> 
> Who are members of that community?
> 
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
> 
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
> 
> 
> 
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>>
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
> 
> That's a chicken-and-egg problem.
> 
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>>
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
> 
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
> 
> "enable" is something like "available", "allow to exist".
> 
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
> 
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
> 
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
> 
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
> 
>    However, I will caution that it is becoming increasingly difficult for people
>    to find time to review potential new LSMs so it may a while to attract sufficient
>    comments and feedback.
> 
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
> 
> It is exactly "only in-tree and supported by distributors is correct" crap.
> 

for some users, but having a very well defined support surface also has its
place. From a distro POV support is expensive and its amazing what users
will do and try to hide while trying to get support.

Personally I prefer splitting enable and support but there are situations
where that isn't even allowed (some certifications). So I can understand
where they are coming from.

It just sucks for the users and projects that aren't "supported".

> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.

Does anyone?

> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
> 
you are more optimistic than I am. What makes you think a distro like RH will
enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
that is already in the kernel.

If loadable LSM modules are allowed, there will likely be a kernel config
to disable them and there will definitely be an interface that allows
blocking them. So whether via config option or run time control I don't
see RH allowing them.

> 
> 
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
> 
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
> 
>    Simply put, we do not have the time to deal with any potential kernel bug
>    reports that would come from enabling TOMOYO.  It would be a disservice to
>    our users to enable something we have no intention of attempting to fix
>    when it is broken.
> 
> did not happen, and
> 
>    Even if it was 100% perfect code and caused no bug reports for the kernel,
>    it is still bloat and while it might not seem like it we are actually
>    trying to cut down on the size of our installed kernels.
> 
> can be solved by allowing loadable module LSMs.
> 
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
> 

sadly I really don't think it will

> 
> 
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
> 
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
>