5 ms·
Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last m
by zanny 7y ago
Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work.
Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential malware vectors - both exploited software and injected binaries. GUI desktops could have provided UI to prompt users for unknown programs trying to access specific things and then send reports upstream of programs allowed for review. It would practically be a self-building database of program file access if done right.
But that isn't the only avenue to it. You could pressure upstream to include discriptor files in git repos of a standardized format of file access for each binary that can be used to generate selinux / apparmor / tomoyo rules. You could do it the really hard way and just have a sprint to surface test every program in official repos and generate such files yourself. Programs should almost never be accessing anything outside their XDG conf file and data dir - they should be linking libraries to provide access to other stuff (input, gui, etc) and file access should go through the system wide file picker.
As it is right now though pretty much every executed binary on most Linux systems is allowed to do whatever it wants that it has user access privilege to. Especially because most maintainers don't want to have to bother with the complaints of malcontent software breaking constantly trying to read arbitrary files. The Apparmor profiles of SUSE / Ubuntu or SELinux of Fedora are largely written for a few specific programs, usually web browsers and file sharing daemons, rather than be comprehensive. Its such a shame that all the technologies exist and are in place to make this work (even Arch has Apparmor support in its official repos now!) but there is no willpower / capital / interest in going the last step and trying to be all encompassing in your MAC profile and then lock down unknown programs appropriately. Android pretty much does this already, its a shame desktop Linux totally skipped over this avenue towards secure desktops.
There is of course an argument that if you lock down programs with network access then thats all you need to secure your desktop but that position falters in the face of arbitrary programs being run at random that can include network access. The goal should be a default restricted profile - one where arbitrary binaries cannot do whatever they want to your system, in the context of having a comprehensive profile database of software being used that covers 99% of real world program usage and thus doesn't impose a sizable UX burden of constant usage prompts for common applications.
- wahern 7y agoThe person best positioned to lock down a program is the developer. Only they know when and how certain resources need to be accessed, and only they are positioned to refactor the source code to maximize the cost+benefit of stricter security policies. But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized. seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized. This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints. Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
- gabcoh 7y agoClaiming the developer is in the best position to lock down there own programs is obviously making the assumption that the developer can be trusted. It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself. I think it would be a great idea to integrate MAC more widely in package distribution systems.