10:50 a.m.
On 9/14/2022 6:57 AM, 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.
The "enable" == "support" model in consistent with the expectations
of
paying customers.
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.
That is correct. Redhat has chosen to support only SELinux. If you want
TOMOYO to be enabled in a distribution you need to sell the value to a
distributor (really, really hard) Or (not recommended) become one yourself.
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.
That's not quite the position. "Only in-tree, and someone has to want to use it
in the real world" is more accurate. Android isn't a distribution, neither is
Tizen. Having a major distributor include the LSM is a big plus.
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.
If LSMs were available to open-source out-of-tree kernel modules, this situation
could be improved.
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.
It sure does. I'm waiting to see what happens if eBPF security modules
become popular. I can easily see distributions turning the BPF LSM off.
> 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.)
Exactly. A module would have to chose between being built-in and being loadable.
Before I go any further, I think that the loadable module manager LSM would be
very hard to get upstream. Most of the arguments against general support for
loadable modules would still apply. It is possible that an acceptable module
could be created, but it would have to address a lot of issues. It is a challenge
I don't expect to accept in this lifetime.