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". Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
