LSM stacking in next for 6.1?

[Paul Moore]

On Thu, Sep 8, 2022 at 11:19 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2022/08/03 9:01, Casey Schaufler wrote:
> > I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> > patch set in the LSM next branch for 6.1. The audit changes have polished
> > up nicely and I believe that all comments on the integrity code have been
> > addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> > There are serious binder changes, but I think they address issues beyond
> > the needs of stacking. Changes outside these areas are pretty well limited
> > to LSM interface improvements.

> Many modules
>
>     SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ）
>     HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ）
>     Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ）
>     LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ）
>     PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ）
>     CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ）
>     SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ）
>     WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ）
>     shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ）
>     S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ）
>
> are proposed 5 or 6 years ago, but mostly became silent...

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.

> I still need byte-code analysis for finding the hook and code for making the hook
> writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks).
> I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/000740.html
> caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.LRH.2.20.1702131631490.8914@namei.org/ .

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.  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.
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).

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.

> 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.  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.

>   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.

>   Instead, Ubuntu users are increasing, but the reason people choose Ubuntu is not because
>   Ubuntu supports AppArmor. Maybe because easy to use container environment. Maybe because
>   available as Windows Subsystem for Linux.

I suspect IBM/RH's decision to change CentOS' relationship to RHEL
also resulted in a number of users moving to Ubuntu, and that has
nothing to do with the LSMs.

>   However, in many cases, it seems that whether the OS is Windows or Linux no longer
>   matters. Programs are written using frameworks/languages which developers hardly care
>   about Windows API or Linux syscall. LSM significantly focuses on syscalls, but the
>   trend might no longer be trying to solve in the LSM layer...

Every LSM is different, that is partly why it is so interesting as a
security framework.  Look at Yama, look at AppArmor, look at Smack,
look at the BPF LSM ... there is no one security model, and claiming
that the LSM focuses on syscalls is misleading.  If you had to pick
only one concept that the LSM focuses on, I believe it would be
providing visibility and access controls for security relevant
interactions between entities on the system.  Processes opening files,
processes executing other processes, processes talking to each other
both across the network and on the local system.  Some of these things
involve syscalls, but as most of us know, making meaningful access
control decisions often involves much more than just the syscall.

> Also, Linux servers started using AntiVirus software. Enterprise AntiVirus software uses
> loadable kernel module that rewrites system call table rather than using LSM interface.
> It seems that people prefer out-of-the-box security over fine grained access control rule
> based security.

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).

I think that is about the nicest thing I can think to say about those
antivirus products ;)

--
paul-moore.com