3 ms·

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone. im not sure what has to change in UX to make these approaches more palatable, but if you have to frequently allow 'good' behaviors, my experience is it never takes off.

__MatrixMan__ 2y ago
I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do. So before running any code you'd hash it and ask your peers: "what do we think this does?" If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised. I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens. It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.
- XorNot 2y ago
  This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions). This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works). AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?). Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?
  - __MatrixMan__ 2y ago
    As far as I'm aware it's missing the consensus part. If I run a program that's not supposed to touch the filesystem in any way, and it does, SELinux doesn't suggest a way for me to circulate this new knowledge among other users of this program--except through its maintainer or that of my Linux distro. And maintainer diligence is over-relied-on as it is. Ideally this sort of thing would work just as well on bits for which there was no clear maintainer. Like if SETI turned up a signal which we can chmod +x and run, we could use it to crowd source an understanding of what it does. A way to hash a file and ask: > What is known about these bits? If it's a popular program and yet none of your peers have seen that hash, maybe you should subject it to more scrutiny than if there's widespread consensus about it (it may have been tampered with).

__MatrixMan__ 2y ago

I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do. So before running any code you'd hash it and ask your peers: "what do we think this does?" If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised. I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens. It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.

XorNot 2y ago
This both is and isn't what SELinux does though: the point of SELinux is when you execute a binary, it runs with whatever context is assigned to it and is bounded by that context (or allowed transitions). This is super powerful to implement exactly that, but for whatever reason IMO it's constantly been half-assed on the UI front, because the best version of it isn't "detailed policy confinements for system software" but detailed confinements for user data (which was the original idea that conceived it at the NSA - the data model ultimately looks a lot like how classified data works). AFAIK the biggest problem is that you can't really do an ACL like configuration for it though - i.e. if I categorize all my SSH keys as type ssh_private_key_t, I'm not able to add an additional tag on that to grant targeted access to a specific program (which both does, and does not make sense - i.e. if I'm handing a program one private key but I think it might leak it...why am I doing that? Conversely in the real world we're bounding risk, so I should be able to do that - I don't think Multi-Category Security fixes this?). Basically "empirical consensus" is an SELinux policy, in fact you can generate one that way - run in permissive mode for an application type, collect the actions as policy, publish for that specific hash...you know I'm honestly wondering if this is just something we need to start doing as an open source service?
- __MatrixMan__ 2y ago
  As far as I'm aware it's missing the consensus part. If I run a program that's not supposed to touch the filesystem in any way, and it does, SELinux doesn't suggest a way for me to circulate this new knowledge among other users of this program--except through its maintainer or that of my Linux distro. And maintainer diligence is over-relied-on as it is. Ideally this sort of thing would work just as well on bits for which there was no clear maintainer. Like if SETI turned up a signal which we can chmod +x and run, we could use it to crowd source an understanding of what it does. A way to hash a file and ask: > What is known about these bits? If it's a popular program and yet none of your peers have seen that hash, maybe you should subject it to more scrutiny than if there's widespread consensus about it (it may have been tampered with).