On 12/12/2018 15:25, Aurelien Jarno wrote:
On 2018-12-12 10:06, Helmut Grohne wrote:Hi Aurelien, On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK this is not done for the default flavour as too options are possible there: - Bind mount like above. This means sharing the shm directory with the outside world. This might have some security implications, and unwanted consequences. - Empty tmpfs like for buildds. This means the processes do not have accesses to shared memory from processes outside of the chroot. Depending on how the user want to use schroot, one or the other configuration should be used. I don't know how we should choose the default one.Essentially, we have three options (for the default and desktop profiles) now: (A) Status quo: Don't mount /dev/shm. (B) Bind mount /dev/shm. (C) Mount a tmpfs on /dev/shm. As you point out, each of (B) and (C) breaks some people's workflows (either isolation or stuff doesn't work). Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own itch, ...) want. (C) doesn't regress on isolation compared to (A). Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.(C) might give users the possibility to trigger an OOM and DoS system. /dev/shm is writable by any user. If users have no limit on the number of chroots they can run, they might be able to fill the whole memory (RAM + swap), leading to an OOM, potentially killing essential services as the memory from a tmpfs can't be killed. This does not happen on a normal system, as the default size of a tmpfs is half of the size of the RAM. So I am not sure that (C) is "strictly better".
It should perhaps be combined with some sensible default size limitations like we used to provide in (IIRC) /etc/default/tmpfs.
For the (B) case, do we have any defined use case for sharing shm between host and chroot? It's useless for anonymous (unlinked) mappings, because they won't be propagated. So the only use case is named mappings. If we don't have any concrete use case for that, I'd be tempted to drop this possibility entirely.
For (A) if you don't mount /dev/shm, is there still some risk due to using the underlying devtmpfs mount and causing problems, including security problems, as a result? You might still get shared data between host and chroots stored there, which might have security and privacy implications? And you could affect the /dev mountpoint if using all the space prevents device node or other file creation under /dev on the host?
I think (C) is vastly preferable from the security point of view. However, it does as you point out, have problems if you overcommit resources across multiple chroots.
One possible mitigation would be to not mount a tmpfs at all. There is no technical requirement that /dev/shm be a tmpfs. It could be backed by disk, e.g. creating and bind mounting chroot/shm to chroot/dev/shm would make it use the same disc backing as the chroot itself. Or create a session-specific private dir under [/var]/tmp and bind mount that (it will avoid serialising and storing session state for source chroots). There will of course be a potential performance cost in using a real disc, but it takes all of the resource exhaustion and privacy questions completely out of the picture.
Regards, Roger