6:32 a.m.
On 2022/09/09 3:52, Paul Moore wrote:
At least one of those, Landlock, has been merged upstream and is now
available in modern released Linux Kernels. As far as the other LSMs
are concerned, I don't recall there ever being significant interest
among other developers or users to warrant their inclusion upstream.
If the authors believe that has changed, or is simply not true, they
are always welcome to post their patches again for discussion, review,
and potential upstreaming. 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.
Inclusion into upstream is far from the goal.
As has been discussed before, this isn't so much an issue with
the
__ro_after_init change, it's really more of an issue of running
out-of-tree kernel code on pre-built distribution kernels, with
"pre-built" being the most important part. It is my understanding
that if the user/developer built their own patched kernel this would
not likely be an issue as the out-of-tree LSM could be patched into
the kernel source.
There always is LSM module which is not enabled in pre-built distribution kernels.
https://bugzilla.redhat.com/show_bug.cgi?id=542986
Even if source code is already available in distribution kernels, as long as
distribution refuses to include into pre-built distribution kernels, it is no
different from the out-of-tree LSM.
The user/developer has to rebuild the whole distribution kernels is an unacceptable
barrier.
The problem comes when the user/developer wants
to
dynamically load their out-of-tree LSM into a pre-built distribution
kernel, presumably to preserve a level of distribution support.
Not only for preserving the level of distribution support. But also for
allowing immediate updates whenever distribution kernels are updated, and
allowing out of kernel modules (e.g. from AntiVirus, hardware vendors) to be
loaded into pre-built distribution kernels (instead of user/developer rebuilt
distribution kernels).
Unfortunately, to the best of my knowledge, none of the major
enterprise Linux distributions will provide support for arbitrary
third-party kernel modules (it may work, but if something fails the
user is on their own to triage and resolve).
I know it, especially Red Hat is strict regarding that. Red Hat does not provide
support for rebuilt kernels even with zero changes (e.g. same kernel source code,
same kernel configuration).
Some hardware vendors provide support for their device drivers when used with
RHEL kernel but does not provide support when used with CentOS kernel (not
CentOS Stream), despite there is effectively no difference. Being able to
continue using pre-built distribution kernels is a fatal requirement for users.
Beyond the support issue, there are likely to be other problems as
well since the kernel interfaces, including the LSM hooks themselves,
are not guaranteed to be stable across kernel releases.
That's not a big problem. Loadable LSM modules will be updated as the kernel
interfaces change.
But the combination of "the kernel interfaces does not legally allow loadable LSM
modules"
and "distributors do not enable LSMs already available in upstream kernels" and
"it is
becoming increasingly difficult for people to find time to review potential new LSMs"
and
"it is difficult for users/developers to continue rebuilding distributor kernels only
for
enabling LSMs" indicates there is no space for LSMs which are not enabled in
pre-built
distribution kernels to survive; it is tantamount to a death sentence.
Legally allowing loadable LSM modules is an answer to current situation.
> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather
than
> "developing security mechanisms". Changes what I found in the past 10 years
are:
>
> As far as I'm aware, more than 99% of systems still disable SELinux.
I would challenge you to support that claim with data.
Unfortunately, that's an impossible request for me. I worked at a support center
for three years, and I found (from e.g. sosreport) that no system enabled SELinux.
Since I already left the support center, I'm no longer in a position who can
collect statistic data.
Granted, we
are coming from very different LSM backgrounds, but I find that number
very suspect. It has been several years since I last looked, but I
believe the latest published Android numbers would give some support
to the idea that more than 1% of SELinux based systems are running in
enforcing (or permissive) mode. Significantly more.
In know-how manuals developed by the support center, disabling SELinux is the
first action after installation, and people using the support center follow it.
(I personally feel that using SELinux with targeted policy is possible. But
they hate troubles caused by unwanted functionality. And they can't afford
keeping SELinux enabled because nobody can adjust policy for their servers.
If troubles caused by SELinux happen, even I won't be able to provide support
because I'm not in a position to understand and manage the details/usage of
their servers.)
You might wonder how they are protecting their servers without SELinux.
It is a mystery.
But I if recall the days at the support center, I seldom saw servers which
directly face the Internet. Maybe they are using security appliance for servers
facing the Internet, and using RHEL for servers in already secured environment.
Then, the need to enable SELinux remains still low sounds realistic.
For example, telnet and ftp are used even nowadays in some systems.
https://bugzilla.redhat.com/show_bug.cgi?id=1853102
https://bugzilla.redhat.com/show_bug.cgi?id=1914536
But again, I'm not in a position for collecting statistic data.
> People use RHEL,
> but the reason to choose RHEL is not because RHEL supports SELinux.
Once again, if you are going to make strong claims such as this,
please provide data. I know of several RHEL users that are only able
to run SELinux based systems as it is the only LSM which meets their
security requirements.
Sure, there are systems where SELinux is the only choice.
But surely there are systems where SELinux is not the only choice.
I would caution against confusing the security policy driven access
controls provided by many in-tree LSMs with out-of-tree antivirus
software. They have different goals, different use cases, and
different user groups (markets).
But due to the above-mentioned death sentence, we currently can't allow
users/developers to use different LSMs which have different goals,
different use cases, and different user groups (markets). Very bad...