Re: [PATCH -next 0/2] lsm: Change inode_setattr() to take struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]
  Powered by Linux