On Wed, May 9, 2018 at 10:19 AM, Alec Warner <anta...@gentoo.org> wrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turner <matts...@gentoo.org> wrote: >> >> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devuran...@gmx.net> >> wrote: >> > Hello! >> > >> > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ >> > renderD128" pop up for more and more packages, probably since OpenCL >> > becomes >> > used more widely. Hence I would like to ask: Could we in Gentoo treat >> > GPUs >> > just like CPUs and allow any process to access render nodes (i.e. the >> > GPUs >> > compute capabilities via the specific interface the Linux kernel's DRM >> > offers >> > for that purpose) without sandbox restrictions? >> > >> > --Dennis >> > >> > See-Also: https://bugs.gentoo.org/654216 >> >> This seems like a bad idea. With CPUs we've had decades to work out >> how to isolate processes and prevent them from taking down the system. >> >> GPUs are not there yet. It's simple to trigger an unrecoverable GPU >> hang and not much harder to turn it into a full system lock up. >> >> >> This is not safe. >> > > Is the sandbox considered a security boundary? Certainly in earlier > (LD_PRELOAD based) implementation it was not. > Instead it was intended to protect the build environment from leaks (e.g. > accessing unwanted host state in the build env.) > > Sure it also in theory prevented build environments from writing to the > host; but it didn't do a very secure job of it.
I don't know. Irrespective to the answer to that question, it's my opinion that we should not execute code via the package manager that has the potential to bring down the whole system.
