|
I spent a few years working on general-purpose security sandboxing for Linux desktop apps (as a master's thesis), and gave up. The problem is that there are a bunch of common-sense things like not giving access to the root filesystem, and a million less common-sense things that also give you the ability to escape the sandbox. It really sucks. There's X11, as Alex mentioned. If you grant permissions to an app to use the X11 socket, it has the ability to inject keystrokes to any other application in the same X session. If you have a terminal open where you run "sudo", then the app can gain root. Your gparted example gives the app access to the root partition. This allows it the ability to modify anything on the drive without going through the filesystem's security layer. It can go change root's password, modify setuid binaries, etc. It can then flush the disk cache by reading a lot of something else, ensuring that the next time the kernel wants to check root's password, it won't be cached. Also, the state of the Linux kernel is such that if an app is running as UID 0 (even within a container), it probably has the ability to exploit some subtlety in the kernel interface to gain root. This is much reduced if you're using user namespaces (which, AIUI, Docker is not yet using), but it's still a risk. It's a huge risk without user namespaces. If you trust the app, then you don't need an app (security) sandbox, which I think is what Alex is saying: "This is not sandboxing." If you don't trust the app, then Docker will not effectively restrict what the app can do to your system. |