On Wed, 20 May 2020 14:47:52 -0700 "Greg A. Woods" <wo...@planix.com> wrote:
> Well if all your chroot tree of processes runs as a single unique user > then from what I understand secmodel_extensions "Curtain Mode" already > does actually do all of the rest of what you need. > Curtain mode does not. Some applications run as multiple processes with multiple users, by design. Curtain mode as I understand it would tear these apart. In addition, if I'm reading the documentation correctly - multiple instances of the same application- or any two applications sharing the same UID - would be able to interact. That is not isolation. Multiple instances is a real world scenario, not something hypothetical. I had four instances of PostgreSQL running on the same machine in individual chroot's until recently. Maybe "segment processes by process group id", not user id, is what I'm asking for. But the possibility of having multiple process groups in the same segment is also something to worry about. Curtain Mode sounds great for a system where dozens of human users are logged in on one machine, but I have not seen that situation very often. > So, is it necessary to support setuid binaries in a shared filesystem > used to underly chrooted processes? > For my specific use case, I don't think so. Processes are launched from an external command that calls chroot, then switches to an unprivileged UID as needed, then calls exec. > In the mean time one could argue "disk is cheap" and say that every > chrooted service gets its own copy of the file tree. > 'Disk is cheap' is an understatement - my services are built from a program which takes a Yaml-formatted manifest file and pulls in only what's needed, checking 'ldd' for ELF binaries. The resulting nginx chroot is 8 megabytes when tarballed; MySQL is only 32 megabytes if the documentation is excluded. On one of my production hosts right now, not a single chroot is more than a gigabyte. The data used by these services (/var/www, /var/lib/mysql, etc) isn't included in the count, as that is brought in from elsewhere using null mounts. There are pros and cons to this approach, but disk space was not a factor in the decision. There's still networking to worry about after that, but just isolating processes in a more useful way is a huge step forward. -- Aaron B. <aa...@zadzmo.org>
