Message-ID: <97b35d43-337f-9cac-0a0b-86b216fce594@gmail.com>
Date:   Wed, 31 May 2023 12:31:32 -0700
From:   Jay Freyensee <why2jjj.linux@...il.com>
To:     Christian Brauner <brauner@...nel.org>,
        Casey Schaufler <casey@...aufler-ca.com>
Cc:     Christoph Hellwig <hch@....de>,
        Mickaël Salaün <mic@...ikod.net>,
        Xiu Jianfeng <xiujianfeng@...wei.com>,
        gregkh@...uxfoundation.org, rafael@...nel.org,
        viro@...iv.linux.org.uk, dhowells@...hat.com, code@...icks.com,
        hirofumi@...l.parknet.co.jp, linkinjeon@...nel.org,
        sfrench@...ba.org, senozhatsky@...omium.org, tom@...pey.com,
        chuck.lever@...cle.com, jlayton@...nel.org, miklos@...redi.hu,
        paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
        stephen.smalley.work@...il.com, eparis@...isplace.org,
        dchinner@...hat.com, john.johansen@...onical.com,
        mcgrof@...nel.org, mortonm@...omium.org, fred@...udflare.com,
        mpe@...erman.id.au, nathanl@...ux.ibm.com, gnoack3000@...il.com,
        roberto.sassu@...wei.com, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-cachefs@...hat.com,
        ecryptfs@...r.kernel.org, linux-cifs@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
        wangweiyang2@...wei.com
Subject: Re: [PATCH -next 0/2] lsm: Change inode_setattr() to take struct


On 5/30/23 9:01 AM, Christian Brauner wrote:
> On Tue, May 30, 2023 at 07:55:17AM -0700, Casey Schaufler wrote:
>> On 5/30/2023 7:28 AM, Christoph Hellwig wrote:
>>> On Tue, May 30, 2023 at 03:58:35PM +0200, Christian Brauner wrote:
>>>> The main concern which was expressed on other patchsets before is that
>>>> modifying inode operations to take struct path is not the way to go.
>>>> Passing struct path into individual filesystems is a clear layering
>>>> violation for most inode operations, sometimes downright not feasible,
>>>> and in general exposing struct vfsmount to filesystems is a hard no. At
>>>> least as far as I'm concerned.
>>> Agreed.  Passing struct path into random places is not how the VFS works.
>>>
>>>> So the best way to achieve the landlock goal might be to add new hooks
>>> What is "the landlock goal", and why does it matter?
>>>
>>>> or not. And we keep adding new LSMs without deprecating older ones (A
>>>> problem we also face in the fs layer.) and then they sit around but
>>>> still need to be taken into account when doing changes.
>>> Yes, I'm really worried about th amount of LSMs we have, and the weird
>>> things they do.
>> Which LSM(s) do you think ought to be deprecated? I only see one that I
> I don't have a good insight into what LSMs are actively used or are
> effectively unused but I would be curious to hear what LSMs are
> considered actively used/maintained from the LSM maintainer's
> perspective.

It's part of my job to look at functionality enabled by LSMs and how 
they can be applied to product security features and products at the 
distro level.

First of all the flexibility of stacking LSM's has greatly helped enable 
new and more features to be run at the same time on a Linux platform.

So there are feature buzz words out there, the main ones I'm familiar 
with,  like process control, anti-tampering/self-protect, quarantine, 
process injection.  The LSM's I've tried to follow w/respect to these 
features have included SELinux, AppArmor, yama, bpf/krsi, landlock, and 
safesetid.

Usually for process control ppl are most interested in killing a process 
quickly if its detected a threat.  In that end bpf/krsi LSM is a 
wonderful LSM for this and puts Linux on par with Windows and macOS with 
this feature (though the actual kill operation seems slower).

anti-tampering/self-protect is a mechanism to prevent say, an anti-virus 
program from getting killed by a threat process even if that process has 
root.  I believe this could be done via SELinux, Apparmor, maybe bpf, 
and maybe landlock.  In comparison, macOS does have this functionality 
via its Endpoint Security subsystem.

process injection would be a way to monitor a process which, yama would 
have to be turned off which then a customer would have to make a call if 
they want the protection of yama's disablement of tracing over whatever 
process injection feature the security company may be offering.

Quarantine is a way to sandbox a process that has not been determined to 
be a threat or not (unknown) and can be stored "for later (later 
termination or save-keeping for study".  That would be a neat future 
LSM, one I thought could be tacked onto landlock (but from what I 
understand would require the use of cgroups).

And speaking of future LSMs, I read one proposal I saw that I thought 
was a good idea called the NAX driver that was something like the the 
yama driver, only its sole purpose was to shut off the anonymous 
executable pages for fileless malware protection. But it didn't look 
like it got anywhere.

Some interesting usages/beliefs of LSM's I've seen:

*Using SELinux over AppArmor will help a security solution company win a 
govt contract due to the NSA relationship with SELinux.

*The belief lockdown will shut off or cause issues with ebpf, thus its 
not activated and used much.

*RHEL 8.7 having yama driver set to 0 upon install, which I thought the 
kernel Kconfig default was 1? So it makes me wonder what other distro 
installs set yama to 0 by default? Maybe yama causes an issue with 3rd 
party SW if its enabled to 1->3.


If you want to look at a security product making use of LSM's, check out 
KubeArmor.

Hope this helps...someone :-)

Powered by blists - more mailing lists