Performance impact

Posted Aug 8, 2022 22:43 UTC (Mon) by cschaufler (subscriber, #126555)
In reply to: Performance impact by Cyberax
Parent article: Security requirements for new kernel features

As others have pointed out, all Redhat desktops ship with SELinux full-up enabled. Ubuntu ships with AppArmor. I personally have systems running with both SELinux and AppArmor. Some with Smack and AppArmor, too. And there's every cloud provider, every phone and almost every IoT device. When we search our souls it's not about whether we should do a better job of getting out of the way, it's about how we can provide more of the features developers are screaming for and still maintain performance. If you are content with access controls from the 1970's I'm fine with that. But that puts you as far outside the mainstream as Bell & LaPadula was in 1984.

Performance impact

Posted Aug 8, 2022 22:57 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

I have yet personally to see a person with SELinux enabled. I don't see Fedora desktops often, but all the people I know that are using them have SELinux disabled because they work on low-level stuff.

AppArmor in Ubuntu is a bit more sane, because it doesn't require crazy labelling and impenetrable policies.

> And there's every cloud provider

Not every. And I know how one large provider works internally (a couple of years outdated, but I doubt it has changed much).

Heck, here's what EC2 offers for their own supported in-house distribution:

> [ec2-user@ip-172-31-0-166 ~]$ getenforce
> Disabled

> When we search our souls it's not about whether we should do a better job of getting out of the way, it's about how we can provide more of the features developers are screaming for and still maintain performance.

How long did it take to build stackable LSMs? For a decade the inability to run multiple LSMs made anything but SELinux/AppArmor impractical.

Sorry. But right now LSMs are just an impediment that most people try to wave away so it won't bother them. Large companies like Google have time and money to invest in getting it into shape, sure. But that's a far cry from being a useful and productive feature. Unlike cgroups or namespaces that are widely accepted by developers.

Performance impact

Posted Aug 9, 2022 16:16 UTC (Tue) by cschaufler (subscriber, #126555) [Link] (7 responses)

Stacking LSMs could have been completed a decade ago had it not been for some of the design choices forced upon the security module developers to ensure that performance impact on systems that don't use LSMs is minimized. I understand and appreciate that in whatever subset of the Linux development community you reside LSM is not considered useful. I personally have little interest in the device driver infrastructure, which many developers consider most critical. I am concerned that work I do in LSM does not interfere with device drivers *to the extent possible*. If you need to blame CAP_SYS_ADMIN on somebody, I'm probably the best target. The Linux kernel does lots of things for lots of reasons. I have no idea what you work on, or why, but I'm willing to wager a refreshing beverage that we could have made security a much bigger pain than it is now.

Performance impact

Posted Aug 9, 2022 20:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> I understand and appreciate that in whatever subset of the Linux development community you reside LSM is not considered useful.

It's not that it's not useful, additional mitigations are great. It's that the amount of effort that needs to be expended to make use of SELinux is just not comparable with the amount of protection it provides. I long ago tried to make sense of policies and to create my own toy policies, but failed miserably. TOMOYO is rigorously undocumented and I haven't touched Smack because it doesn't even look in any way "simplified".

AppArmor is a bit better, since it at least doesn't require labelling across all of the filesystem which is nothing but security theater compared to just using paths. Its policies are also easier to understand.

One feature that I really personally would have liked is an ability to use LSMs to _grant_ permissions instead of taking them away.

Performance impact

Posted Aug 9, 2022 20:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

And yeah, at this point I'd just prefer a well-tailored ad-hoc solution like pledge()/unveil() in OpenBSD to the generalized LSM system that Linux has.

Authoritative hooks

Posted Aug 9, 2022 20:29 UTC (Tue) by corbet (editor, #1) [Link] (4 responses)

It seems you have one point of agreement with Casey, anyway: at one point, at least, he too wanted authoritative hooks in the LSM subsystem.

Authoritative hooks

Posted Aug 10, 2022 21:39 UTC (Wed) by cschaufler (subscriber, #126555) [Link] (3 responses)

Had we adopted authoritative LSM hooks the landscape would be very different indeed. Stacking of modules would have been impossible. What would happen if module A said "yes" and module B said "no"? You'd have to define some sort of peeking order for the modules, which wouldn't make each module authoritative now, would it? What we could do is refactor the traditional Linux discretionary controls into an LSM and insert it at the front of the list. You could then implement POSIX ACLs in an LSM, replacing the mode-bit only hooks with ACL cognizant ones. To forgo DAC all you would have to do is drop that module from the list. Now I suppose one might only want to drop certain of the controls (e.g. signal delivery ) and not the whole set. That's solvable, but hideous. Too much "fine granularity" for my taste.

Authoritative hooks

Posted Aug 11, 2022 0:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Had we adopted authoritative LSM hooks the landscape would be very different indeed. Stacking of modules would have been impossible. What would happen if module A said "yes" and module B said "no"?

Various systems (like IAM policies in AWS or ACLs in Windows) typically consider "Deny" to be a veto on any allowing ACLs/policies.

Authoritative hooks

Posted Aug 11, 2022 17:50 UTC (Thu) by cschaufler (subscriber, #126555) [Link] (1 responses)

This is exactly the "bail on fail" model of permissive hooks that we have today. What you can't do is what you had asked for, which is to provide a mechanism for a hook to grant access instead of denying it as would occur otherwise. We could make it possible, but that would have -- wait for it -- performance impact. :)

Authoritative hooks

Posted Aug 11, 2022 18:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> What you can't do is what you had asked for, which is to provide a mechanism for a hook to grant access instead of denying it as would occur otherwise.

That would actually help and make time investment into SELinux be worthwhile, as it will open up _new_ possibilities. Performance impact is another question, and it'd be interesting to see if removing the DAC entirely in favor of MAC would help.

Performance impact

Posted Aug 23, 2022 7:26 UTC (Tue) by daenzer (subscriber, #7050) [Link]

> I don't see Fedora desktops often, but all the people I know that are using them have SELinux disabled because they work on low-level stuff.

I've been working on the graphics stack (mostly between Mesa / mutter / Xwayland) as part of the Red Hat desktop group for 3 years. In this time, I've never had to disable SELinux on Fedora. AFAIK my colleagues are leaving it enabled as well.

There can sometimes be minor SELinux related issues when upgrading to a new beta release, but those are usually quickly fixed.

It seems to me what you think you know about this is hearsay and/or outdated.