3 ms·

> The entire app isn't sandboxed -- just the code that does video parsing, i.e. with the thousands of bugs and hundreds of remote code execution exploits (!).

by jbk 13y ago

> The entire app isn't sandboxed -- just the code that does video parsing, i.e. with the thousands of bugs and hundreds of remote code execution exploits (!). The exploits are usually on the protocol (access) level, the demuxer (format) level but also the decoder level. While in theory the first 2 are what you call parsing, many security issues appear also at the decoder level. And if you want to split the video decoder from the rendering, you need to introduce an additional memcpy (or two) of full decoded frames, which has an important impact. I agree it would be nice to try, with a correct, separated processes architecture, but it means changing also a bit the usual architecture, where there is a direct-rendering between the decoder and the output.

ori_b 13y ago
What you do is split the file I/O from the rendering. Drop privs on the renderer, and feed it data from another process that handles the file access, setup, and other privileged operations. You can open your X11 socket (or whatever your GUI uses) in the I/O process and hand it off to the renderer before dropping privileges, and hand it off without any loss of performance. Another thought -- although I don't generally touch 3d rendering, or know enough to know if it's possible off the top of my head -- is something like cross-process pbuffers: you render into one, and composite the result to the screen from another process. Since your OS already does this sort of thing (X11 compositors, for example, do this sort of cross-process compositing), this can't be too expensive. You might need to use the XACE extension to restrict the renderer to just the rendering output window in case it gets exploited, so that you don't have access to the rest of the UI. The places where vulnerabilities can do damage are when communicating with the rest of the OS: File I/O allows you to get user data, permanently install malware, and delete things. The window system allows you to snoop keystroke/mouse data, synthesize input, and watch what the user does. Drop privs on those, and your app is fairly effectively sandboxed.

by jbk 13y ago

ori_b 13y ago

What you do is split the file I/O from the rendering. Drop privs on the renderer, and feed it data from another process that handles the file access, setup, and other privileged operations. You can open your X11 socket (or whatever your GUI uses) in the I/O process and hand it off to the renderer before dropping privileges, and hand it off without any loss of performance. Another thought -- although I don't generally touch 3d rendering, or know enough to know if it's possible off the top of my head -- is something like cross-process pbuffers: you render into one, and composite the result to the screen from another process. Since your OS already does this sort of thing (X11 compositors, for example, do this sort of cross-process compositing), this can't be too expensive. You might need to use the XACE extension to restrict the renderer to just the rendering output window in case it gets exploited, so that you don't have access to the rest of the UI. The places where vulnerabilities can do damage are when communicating with the rest of the OS: File I/O allows you to get user data, permanently install malware, and delete things. The window system allows you to snoop keystroke/mouse data, synthesize input, and watch what the user does. Drop privs on those, and your app is fairly effectively sandboxed.