3 ms·

What's the preferred method of limiting permissions then? Virtualization? Containerization? AppArmor?

christophilus 3y ago
I use containerization, but it’s not perfect. Also on the front page today: https://news.ycombinator.com/item?id=39250975 https://news.ycombinator.com/item?id=39250975
PhilipRoman 3y ago
For normal services namespaces are enough (make sure to set no_new_privs, one of the best Linux features). Run it with the bare minimum of mounts required, no shared /tmp, etc. For all its faults, systemd actually gets this right, by allowing to easily harden services. Note that this exploit relies on being able to run as root (typically through setuid). If you don't fully trust a service, don't let it ever talk to code running as root in the first place. No opening sockets in /tmp, no listing processes in /proc, no dbus shenanigans, no sudo or su. One of this issues with this was that some programs require setuid for bad reasons (IIRC historically ping was setuid to be able to send ICMP packets). From a quick check (find -type f -perm -4000) most of these problems have been eliminated, via linux capabilities or otherwise. These tactics successfully saved me from log4shell.
worksonmine 3y ago
Depends on what you want to achieve. AppArmor/SELinux prevent access to files and directories. Virtualization and containerization tries to build a jail. You can combine the solutions, a container running a distro with SELinux like any from the Red Hat ecosystem. They have all had vulnerabilities, My preferred method is to not install stuff I don't need, and fix any dangerous configuration for the programs I do need. I prefer Podman over Docker because of rootless for example.
marcosdumay 3y ago
Containerization doesn't protect at all against privilege escalation. And AppArmor is a very partial improvement. The way to protect against this is with an external supervisor. But then you have to care about privilege escalations attacks against the supervisor. Hopefully that one is much simpler than Linux so it has much fewer vulnerabilities.
tempmac 3y ago
extra laptops/servers...? meh
dmm 3y ago
On Linux, Chromium uses setuid or user namespaces to restrict the access of sandboxed components and seccomp-bpf to reduce the kernel attack surface. Check out the Chromium docs on this topic: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

I use containerization, but it’s not perfect. Also on the front page today: https://news.ycombinator.com/item?id=39250975 https://news.ycombinator.com/item?id=39250975

PhilipRoman 3y ago

For normal services namespaces are enough (make sure to set no_new_privs, one of the best Linux features). Run it with the bare minimum of mounts required, no shared /tmp, etc. For all its faults, systemd actually gets this right, by allowing to easily harden services. Note that this exploit relies on being able to run as root (typically through setuid). If you don't fully trust a service, don't let it ever talk to code running as root in the first place. No opening sockets in /tmp, no listing processes in /proc, no dbus shenanigans, no sudo or su. One of this issues with this was that some programs require setuid for bad reasons (IIRC historically ping was setuid to be able to send ICMP packets). From a quick check (find -type f -perm -4000) most of these problems have been eliminated, via linux capabilities or otherwise. These tactics successfully saved me from log4shell.

worksonmine 3y ago

Depends on what you want to achieve. AppArmor/SELinux prevent access to files and directories. Virtualization and containerization tries to build a jail. You can combine the solutions, a container running a distro with SELinux like any from the Red Hat ecosystem. They have all had vulnerabilities, My preferred method is to not install stuff I don't need, and fix any dangerous configuration for the programs I do need. I prefer Podman over Docker because of rootless for example.

marcosdumay 3y ago

Containerization doesn't protect at all against privilege escalation. And AppArmor is a very partial improvement. The way to protect against this is with an external supervisor. But then you have to care about privilege escalations attacks against the supervisor. Hopefully that one is much simpler than Linux so it has much fewer vulnerabilities.

tempmac 3y ago

extra laptops/servers...? meh

dmm 3y ago

On Linux, Chromium uses setuid or user namespaces to restrict the access of sandboxed components and seccomp-bpf to reduce the kernel attack surface. Check out the Chromium docs on this topic: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...