On Fri, Sep 22, 2017 at 7:43 PM, James McMechan <james_mcmec...@hotmail.com> wrote:
> Hello, > I thought a example of how a overlay sandbox could work was in order. > > ### > # load the overlayfs filesystem for this test > modprobe overlay > > # make the directories for the test > mkdir -p /var/tmp/upper /var/tmp/work /mnt/gentoo > > # now create a separate mount namespace non-persistent > unshare -m bash > > # setup the overlay > mount -toverlay -oupperdir=/var/tmp/upper/,workdir=/var/tmp/work/,lowerdir=/ > overlay /mnt/gentoo/ > > # since I don't care about protecting /var/tmp/portage > # put the original on top of the overlay for better performance maybe? > mount -o bind /var/tmp/portage /mnt/gentoo/var/tmp/portage > > # then like the handbook > cd /mnt/gentoo > mount -t proc proc proc > mount --rbind /sys sys > mount --rbind /dev dev > > #finally change into the protected sandbox > chroot . bash > > # mess up the system > > exit # the chroot > exit # the unshare > ### done. > > This version allows the sandbox to work with the special files in /dev, > /proc, /sys > other options are available for example a second separate dev/pts and > dev/shm submounts > > When you exit the chroot and then the unshare, the /var/tmp/upper > directory will contain all the changes made while in the chroot. > I'm not quite grasping how this informs me of violations though. Like inside of the chroot lets say I read /etc/foo and then modify it (via something like a sed call.) In this implementation /etc/foo is available (because / is lowerdir?) but my writes will end up in /var/tmp/upper. So by simple inspection of /var/tmp/upper I can detect a violation occurred...but I don't get any information as to what caused it; right? I'm sure in trivial cases (sed $FOO) its easy to figure out but other cases its a lot more complicated to determine which portion of the build is the culprit. That is why the tracing portion is so useful. A thing tries to do the bad thing and it fails. We could try forcing failures (say, by not having / mounted as lowerdir, so syscalls against the rootfs would just fail as E_NOENT) but then we are still stuck with the tricky part; which is that sometimes things *do* need to read / write from the rootfs and the sandbox add* API is available to do that. How would we implement something like that here? -A > Enjoy, > > Jim McMechan > >
