4 ms·

I imagine these questions are what might make this project non-trivial, but surely achievable. > If I chroot and then run0 will that process also run in the ch

by _flux 2y ago

I imagine these questions are what might make this project non-trivial, but surely achievable. > If I chroot and then run0 will that process also run in the chroot? That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be that the policy can decide what to do in that case. But wouldn't you agree that it is better security hygiene to explicitly opt-in to inheriting properties when going to an elevated security level, instead of opting out from them?

immibis 2y ago
I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.
- _flux 2y ago
  If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment. But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place. I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try. In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward. In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.

by _flux 2y ago

immibis 2y ago

I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.

_flux 2y ago
If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment. But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place. I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try. In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward. In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.