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
