3 ms·
Keep in mind, systemd is still a default-allow access control list (ACL) and has a very long road ahead in form of Linux security, as long as CAP_SYS_ADMIN cont
by egberts1 2y ago
Keep in mind, systemd is still a default-allow access control list (ACL) and has a very long road ahead in form of Linux security, as long as CAP_SYS_ADMIN continuea to exist.
May make it easier to customize but it doesn't close the security loopholea like SELinux, GRSecurity, TOMOYA, or AppArmor does.
https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html https://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecu...
- detuur 2y agoYes yes and a reminder that BSD Jails are better than anything Linux does and a bunch of other dead horses we like beating on the regular around here. Which is a fanciful way of saying that I don't understand the relevance of your comment at all to the topic at hand, which is an interactive frontend.
- egberts1 2y agoYou read across as a security-indifferent.
- surajrmal 2y agoHonestly it's not all or nothing. It really depends on your threat model. If you assume all native code is both not malicious and incapable of being compromised to run untrusted code then the existing model works. At that point it's more important to focus your security efforts on how native code ends up running, and therefore the distro specific packaging ecosystem. Now for many that threat model is not sufficient as they both run increasingly less trustworthy software, obtained by less trustworthy mechanisms such as npm or off a website, or simply want to protect against bugs that cause otherwise non malicious software from being compromised and resulting in security incidents. I'm in this latter camp but we can't ignore the fact that there are many who happily operate in the former. There also exist solutions such as we browsers with their sandboxes and VMs that somewhat fill the requirements for running untrusted software for these individuals.