4 ms·

Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an

by jbk 9y ago

Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist, MXF or MKV files; - you need the same if ever you have a database of files (media center oriented); - you need raw access to /dev/* to play DVD, CD and other optical disk (and the equivalent on Windows); - you need ioctl on such devices, to pass the MMC for DVD/Bluray; - you need raw access to /dev/v4l* for your webcams and be able to control them; - you need access to the GPU stack, which is running in kernel-mode, btw, to output video and get hw acceleration; - you need access to the audio stack, also in low-level mode; - you need access to the DSP acceleration (not always the GPU); - on linux, you have access to x11 for the 3 above features, which is almost root; - you need access to /etc/ (registry) for proxy informations, fonts configuration and accessibility; - many OpenGL client libraries need access to the /etc too; - you need access to the network, as input and output (think remote control); - you need access to the system settings to disable screensavers, and adjust brightness; - you need access to mounts to be able to see the insertion of DVD/Bluray/USB/SD cards and such; - you need to expose an IPC (think MPRIS on Linux); - you need to unzip, untar, decrypt, decipher and so on; - you need access to the fonts and the fonts configuration (see fontconfig). and I probably forgot one or another case. The point is, all those features have good reasons to exist and very good use cases; but the issue is that for a media player, it will request almost all permissions except GPS and address book. And quite a few of them are very close to kernel mode. So, what is the solution? Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. I've been working on such a prototype, but it's a lot of work... I accept donations :)

viraptor 9y ago
Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Other points may be more tricky, and it's a good list of potential issues, but we can start chipping away some stuff right now. There's a lot we can fix without fixing everything at the same time.
- dom0 9y ago
  > Not even multi-process. Threads on Linux can have their own seccomp profiles. Feels kinda pointless, since all threads in a process share the same memory protection.
  - viraptor 9y ago
    They don't have to. Clone can do a lot of magic without full processes.
    - jbk 9y ago
      But then you need to copy the memory from the decoder to the video output or you get back to the same problem to work-on.
      - Filligree 9y ago
        No, you can use a shared memory segment for a buffer just for that. It's more coding, certainly, but it's possible. Security is an option if we wanted it.
        jbk 9y ago
        That's exactly the point above. See my above comment.
        Filligree 9y ago
        I'm not sure, it sounds like you're saying we'd need to copy memory. The shared memory segment can be a GPU image buffer, so I don't think that's true.
        jbk 9y ago
        See comment above with "the solution". Either you need to have multi-process and correct IPC, or you need to copy.
johncolanduoni 9y ago
> Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. That's not actually how Chrome's renderer sandboxing works. Both Windows and OS X allow you to share a GPU-resident texture between processes (DXGI shared surfaces and IOSurface respectively), so there's no need to copy any video data.
- jbk 9y ago
  But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. The last part is just one of the issues, very far from all of them. Seriously, stop thinking that noone has given a thought to the question...
  - johncolanduoni 9y ago
    I don't think nobody has thought about it, but since you were apparently unaware that there was an alternative to performing several GB/s of IPC for moving buffers around there's obviously some options that haven't been considered. The Chromium sandbox has to deal with every issue you've listed (it's even calibrated to run ffmpeg inside the sandbox, since that's something Chromium needs to do).
    - jbk 9y ago
      > but since you were apparently unaware that there was an alternative I will refrain from answering to such attacks. As you seem to know better, I'm waiting for your patches.
      - johncolanduoni 9y ago
        It's not an attack. Each platform's methods of GPU IPC are pretty sparsely documented. Two months ago I wouldn't have known about them; I only learned by working on integrating Chromium's sandbox into an application that needed to work with the GPU within a sandboxed process. That doesn't change the fact that none of the things you listed are unsupported by Chrome's sandbox model, and if you only need to establish a barrier around the video pipeline (and not e.g. VLC's ability to notice device status or interact with webcams) you don't even need 3/4 of what Chromium's sandbox has implemented. Like I said, I've actually walked the walk when it comes to using their sandbox for Windows and Linux with a process that needed to access certain user files, the GPU, and even each platform's font server equivalent, so this isn't me just spitballing about some theoretical solution.
adgasf 9y ago
Interesting. I am only interested in these features: - you need access to the GPU stack, which is running in kernel-mode, btw, to output video and get hw acceleration; - you need access to the audio stack, also in low-level mode; - you need access to the DSP acceleration (not always the GPU); - you need access to the system settings to disable screensavers, and adjust brightness; - you need to unzip, untar, decrypt, decipher and so on; - many OpenGL client libraries need access to the /etc too; Is there a lighter version where these features are cut? - you need to be able to open files without user interactions (no file picker), in order to open playlist, MXF or MKV files; - you need the same if ever you have a database of files (media center oriented); - you need raw access to /dev/* to play DVD, CD and other optical disk (and the equivalent on Windows); - you need ioctl on such devices, to pass the MMC for DVD/Bluray; - you need raw access to /dev/v4l* for your webcams and be able to control them; - on linux, you have access to x11 for the 3 above features, which is almost root; - you need access to /etc/ (registry) for proxy informations, fonts configuration and accessibility; - you need access to the network, as input and output (think remote control); - you need access to mounts to be able to see the insertion of DVD/Bluray/USB/SD cards and such; - you need to expose an IPC (think MPRIS on Linux); - you need access to the fonts and the fonts configuration (see fontconfig).
- jbk 9y ago
  The first part are the dangerous parts.
jbverschoor 9y ago
You actually don't NEED a lot of these things I'm perfectly fine with a default / embedded font. I don't have an optical drive A database can be in the local app storage. I'm fine opening a subtitle file myself. Why would I need IPC? Why would I need to unzip anything? If it's subtitle files, it can be done in-memory. Are you sure we need low-level audio? I don't have a remote, so I'd like it to be disabled by default. I don't need any access to the network. etc. etc. etc
- oblio 9y ago
  Congratulations, you don't need those things. What about the other 19.999.999* users? Are you sure they don't need any of those things? :) * Arbitrary number.
- thirdsun 9y ago
  That's you. Most users expect one or more of the other mentioned features.
- stordoff 9y ago
  Those restrictions work for you, but would make VLC borderline useless for me. > I don't need any access to the network. 90+% of what I use it for comes from my NAS or the Internet. > I don't have an optical drive Most of the rest is from optical discs. > I'm perfectly fine with a default / embedded font. [...] I'm fine opening a subtitle file myself. It's _fine_ but far from ideal. Both are useful quality of life features. > Why would I need to unzip anything? Non-essential, but being able to play video from a ZIP is a useful feature.
- Brockenstein 9y ago
  Let's play, "why isn't my use case the only use case."
FrozenVoid 9y ago
All this means Linux is misdesigned for user apps, forcing low-level code instead of proper APIs. Maybe stuffing everything into the kernel isn't a good idea after all? All these things are exploit attack surfaces.
justin66 9y ago
What features could the OS offer you (to help your program be "sandboxed") that it currently does not?
- jbk 9y ago
  I think we can do everything now for the majors OSes, but I'd guess this is a 50-100 man-month work for VLC.
phkahler 9y ago
Thanks for that. This type of thing comes up all the time. I used to wonder how web sites could be so dangerous, but it becomes clear when you think about all the extra access developers wanted for good reasons - imagine a web browser that didn't have access to the file system, and so on. I still don't like this state of affairs, but I don't have an alternative solution. Wayland should be more secure than X, but they're starting to poke holes in there for various reasons (color picker, warp pointer for compat, etc...).
fulafel 9y ago
You don't need special fast IPC. Even uncompressed video is fine over standard IPC.
- jbk 9y ago
  Blurays are 60Mbps. Then with 40k60 + HDR, displaying is quite a lot of bandwidth.
  - fulafel 9y ago
    A 10 year old PC carries 2.1 GiB/s (= 17 Gbps) over bog standard pipes without tuning or parallelism, as measured by "pv /dev/zero | cat > /dev/null". Uncompressed full HD is 1.5-3 Gbps. (Less actually, since codec output is going to be 4:2:2 or similar) Yeah, you can come up with high bandwidth scenarios like stereo VR 144 Hz 4k HDR running on barely capable hardware. But 99% of users don't require such tricks and never see any upside from the performance-over-security compromise. Even if you decide basic IPC is not fast enough, a shared memory buffer for raw frame data is reasonably secure too.
    - jbk 9y ago
      Knowing that today we still see bandwidth issues in VLC, even without IPC, I kind of doubt it.

by jbk 9y ago

viraptor 9y ago

Not even multi-process. Threads on Linux can have their own seccomp profiles. You don't need to sandbox absolutely everything at the same time either. In this case opening the file in the main, unrestricted app and spawning a new thread that will read from the existing FD and only send you simple, time sorted messages over a shared IPC/pipe is not that crazy. Other points may be more tricky, and it's a good list of potential issues, but we can start chipping away some stuff right now. There's a lot we can fix without fixing everything at the same time.

dom0 9y ago
> Not even multi-process. Threads on Linux can have their own seccomp profiles. Feels kinda pointless, since all threads in a process share the same memory protection.
- viraptor 9y ago
  They don't have to. Clone can do a lot of magic without full processes.
  - jbk 9y ago
    But then you need to copy the memory from the decoder to the video output or you get back to the same problem to work-on.
    - Filligree 9y ago
      No, you can use a shared memory segment for a buffer just for that. It's more coding, certainly, but it's possible. Security is an option if we wanted it.
      - jbk 9y ago
        That's exactly the point above. See my above comment.
        Filligree 9y ago
        I'm not sure, it sounds like you're saying we'd need to copy memory. The shared memory segment can be a GPU image buffer, so I don't think that's true.
        jbk 9y ago
        See comment above with "the solution". Either you need to have multi-process and correct IPC, or you need to copy.

johncolanduoni 9y ago

> Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. That's not actually how Chrome's renderer sandboxing works. Both Windows and OS X allow you to share a GPU-resident texture between processes (DXGI shared surfaces and IOSurface respectively), so there's no need to copy any video data.

jbk 9y ago
But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. The last part is just one of the issues, very far from all of them. Seriously, stop thinking that noone has given a thought to the question...
- johncolanduoni 9y ago
  I don't think nobody has thought about it, but since you were apparently unaware that there was an alternative to performing several GB/s of IPC for moving buffers around there's obviously some options that haven't been considered. The Chromium sandbox has to deal with every issue you've listed (it's even calibrated to run ffmpeg inside the sandbox, since that's something Chromium needs to do).
  - jbk 9y ago
    > but since you were apparently unaware that there was an alternative I will refrain from answering to such attacks. As you seem to know better, I'm waiting for your patches.
    - johncolanduoni 9y ago
      It's not an attack. Each platform's methods of GPU IPC are pretty sparsely documented. Two months ago I wouldn't have known about them; I only learned by working on integrating Chromium's sandbox into an application that needed to work with the GPU within a sandboxed process. That doesn't change the fact that none of the things you listed are unsupported by Chrome's sandbox model, and if you only need to establish a barrier around the video pipeline (and not e.g. VLC's ability to notice device status or interact with webcams) you don't even need 3/4 of what Chromium's sandbox has implemented. Like I said, I've actually walked the walk when it comes to using their sandbox for Windows and Linux with a process that needed to access certain user files, the GPU, and even each platform's font server equivalent, so this isn't me just spitballing about some theoretical solution.

adgasf 9y ago

Interesting. I am only interested in these features: - you need access to the GPU stack, which is running in kernel-mode, btw, to output video and get hw acceleration; - you need access to the audio stack, also in low-level mode; - you need access to the DSP acceleration (not always the GPU); - you need access to the system settings to disable screensavers, and adjust brightness; - you need to unzip, untar, decrypt, decipher and so on; - many OpenGL client libraries need access to the /etc too; Is there a lighter version where these features are cut? - you need to be able to open files without user interactions (no file picker), in order to open playlist, MXF or MKV files; - you need the same if ever you have a database of files (media center oriented); - you need raw access to /dev/* to play DVD, CD and other optical disk (and the equivalent on Windows); - you need ioctl on such devices, to pass the MMC for DVD/Bluray; - you need raw access to /dev/v4l* for your webcams and be able to control them; - on linux, you have access to x11 for the 3 above features, which is almost root; - you need access to /etc/ (registry) for proxy informations, fonts configuration and accessibility; - you need access to the network, as input and output (think remote control); - you need access to mounts to be able to see the insertion of DVD/Bluray/USB/SD cards and such; - you need to expose an IPC (think MPRIS on Linux); - you need access to the fonts and the fonts configuration (see fontconfig).

jbk 9y ago
The first part are the dangerous parts.

jbverschoor 9y ago

You actually don't NEED a lot of these things I'm perfectly fine with a default / embedded font. I don't have an optical drive A database can be in the local app storage. I'm fine opening a subtitle file myself. Why would I need IPC? Why would I need to unzip anything? If it's subtitle files, it can be done in-memory. Are you sure we need low-level audio? I don't have a remote, so I'd like it to be disabled by default. I don't need any access to the network. etc. etc. etc

oblio 9y ago
Congratulations, you don't need those things. What about the other 19.999.999* users? Are you sure they don't need any of those things? :) * Arbitrary number.
thirdsun 9y ago
That's you. Most users expect one or more of the other mentioned features.
stordoff 9y ago
Those restrictions work for you, but would make VLC borderline useless for me. > I don't need any access to the network. 90+% of what I use it for comes from my NAS or the Internet. > I don't have an optical drive Most of the rest is from optical discs. > I'm perfectly fine with a default / embedded font. [...] I'm fine opening a subtitle file myself. It's _fine_ but far from ideal. Both are useful quality of life features. > Why would I need to unzip anything? Non-essential, but being able to play video from a ZIP is a useful feature.
Brockenstein 9y ago
Let's play, "why isn't my use case the only use case."

FrozenVoid 9y ago

All this means Linux is misdesigned for user apps, forcing low-level code instead of proper APIs. Maybe stuffing everything into the kernel isn't a good idea after all? All these things are exploit attack surfaces.

justin66 9y ago

What features could the OS offer you (to help your program be "sandboxed") that it currently does not?

jbk 9y ago
I think we can do everything now for the majors OSes, but I'd guess this is a 50-100 man-month work for VLC.

phkahler 9y ago

Thanks for that. This type of thing comes up all the time. I used to wonder how web sites could be so dangerous, but it becomes clear when you think about all the extra access developers wanted for good reasons - imagine a web browser that didn't have access to the file system, and so on. I still don't like this state of affairs, but I don't have an alternative solution. Wayland should be more secure than X, but they're starting to poke holes in there for various reasons (color picker, warp pointer for compat, etc...).

fulafel 9y ago

You don't need special fast IPC. Even uncompressed video is fine over standard IPC.

jbk 9y ago
Blurays are 60Mbps. Then with 40k60 + HDR, displaying is quite a lot of bandwidth.
- fulafel 9y ago
  A 10 year old PC carries 2.1 GiB/s (= 17 Gbps) over bog standard pipes without tuning or parallelism, as measured by "pv /dev/zero | cat > /dev/null". Uncompressed full HD is 1.5-3 Gbps. (Less actually, since codec output is going to be 4:2:2 or similar) Yeah, you can come up with high bandwidth scenarios like stereo VR 144 Hz 4k HDR running on barely capable hardware. But 99% of users don't require such tricks and never see any upside from the performance-over-security compromise. Even if you decide basic IPC is not fast enough, a shared memory buffer for raw frame data is reasonably secure too.
  - jbk 9y ago
    Knowing that today we still see bandwidth issues in VLC, even without IPC, I kind of doubt it.