6 ms·

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed" in any fashion. For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. If we want to support the full functionallity for a media player in a sandboxed way we need to start looking into each requirement and designing a safe way to access each item. This is gonna be a lot of work, but I don't see any way around that. For your exact list: Files access can either be granted to the app fully or partially. But we also want some kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things. This could be all from e.g. passing a file descriptor of the opened dvd device to a complete replacement of the subsystem. For an example of the later, for webcams see the pulse-video project: https://github.com/wmanley/pulsevideo https://github.com/wmanley/pulsevideo Is raw audio output necessary? Why does not pulseaudio work? OpenGL access is supported Network access is (optionally, but i think this will be on for most apps) allowed

weland 12y ago
> Is raw audio output necessary? Why does not pulseaudio work? I don't know if this applies to VLC, too, but raw audio output (or something that isn't PulseAudio) is necessary wherever low (or at least constant) latency is required. Edit: oh - now that I look at your username, I believe congratulations are in order re. the subject of this thread :)?
- alexlarsson 12y ago
  PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/ http://www.freedesktop.org/wiki/Software/PulseAudio/Document... That said, I don't think a video player needs low latencies. It can generally have pretty large buffers.
  - riskable 12y ago
    Just to clarify: No one cares if a video player has low-latency audio as long as the audio latency matches the video latency. As in, it totally sucks when the words coming out of an actor's mouth don't line up with the audio. The only place where low-latency matters is real-time encoding situations. For example, video conferencing, composing music, streaming things live, etc but even in those situations "low" is a relative term. Low-latency video conferencing is anything under 200-500ms (depending on who you ask). Low-latency music composition is <20ms (again, depending on who you ask).
    - banjax 12y ago
      Even <20ms is being somewhat generous. I'd just like to see progress TOWARD <20ms on the Android platform. I've been watching this ticket for six years: https://code.google.com/p/android/issues/detail?id=3434 https://code.google.com/p/android/issues/detail?id=3434
  - weland 12y ago
    I think VLC also does recording, but I'm certainly in no position to comment on it. I'm not familiar with their codebase and I don't want to lie :). I don't know what PulseAudio considers "very low latency" and there aren't any numbers on that page to indicate it, but in my experience, PA's best latency possibilities are about an order of magnitude away from being useful for any kind of hardcore real-time processing. This isn't a problem as far as PA is concerned since it's not what it was conceived for, but it won't cut it for applications which need that kind of capability. PA also doesn't really provide latency guarantees, either. In fact, it's mentioned on that page: > So in summary: tell PA what latency you want, but program defensively so that you can deal with getting both lower or higher measured latencies. I don't know if that has improved though. The last time I had to poke PulseAudio was a few months before that page's "Last Edited" timestamp. Edit: For what it's worth: I never managed to get PA to consistently keep latency below 25-30 ms, which is at least 10-15 ms away from being adequate for real-time audio processing. I guess it is a cornercase though, and probably outside the Gnome project's interests. Reading the other comments in this thread, I assume VLC's problems with PA aren't related to latency.
  - 12y ago
Torgo 12y ago
>once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. Wayland fixes this.
- deleted 12y ago
  [deleted]
jbk 12y ago
> It all depends on what your goal is. Well, we've seen sandboxes on other desktop platforms (OSX, WinRT, ChromeOS), and so far, they all are horribly limiting. So, I'm making sure the same does not happen on Linux, before we get kicked out of our own platform. > kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. This is not enough, as explained above. > Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things. Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know. > For an example of the later, for webcams see the pulse-video project: https://github.com/wmanley/pulsevideo https://github.com/wmanley/pulsevideo Something using GStreamer in Vala to get indirect access to webcams? I don't see how this could even work: how do you control brightness or other webcam controls from two applications, how do you get direct H26x access with preview synchronized? (And asking someone to use a competitive project to get video input is also a bit rude, but that's beside the subject) > Why does not pulseaudio work? libpulse requires X, as far as I know. > OpenGL access is supported Through Wayland? How do I get YUV surfaces? What about overlay? What about VDPAU/VAAPI? I guess this will get a lot of improvement, because wayland, wl_scaler (et al) are very limited, so far. We'll see how it fares, but from the past interactions, the answers were pretty dismissive; and therefore, I'm not that optimistic about the outcome.
- alexlarsson 12y ago
  >> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. >This is not enough, as explained above. Well, its hard to say that as this kind of stuff is not designed yet. Better to say that the requirements of VLC on the design of this are more complex than just the "allow access to single-picked-file" semantics. Hopefully we can take this into account when we look into the details here. > Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know. Some of these need not necessarily be as complex as you imagine though. They could very well be some kind of thin service that enumerates the real devices and hands over the opened FD to your app after having verified that it is allowed. > libpulse requires X, as far as I know. Libpulse can optionally be built with X, but this is really only used to read back the pulse socket name from the x root property. It works just fine without X (witness the non-X, but pulseaudio using demo in the blog post for instance). OpenGL access is via DRI, but yeah, output to the screen will have to happen via wayland. That could use subsurfaces with YUV surfaces, and it is then up to the compositor to use overlays if possible (i know weston does this for instance). For VDPAU etc, i don't really know.
asveikau 12y ago
> For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I was not under the impression that xscreensaver in particular is vulnerable to such an attack. I would like to see the code. > Is raw audio output necessary? Why does not pulseaudio work? Funny story, I have never gotten pulseaudio to successfully play any audio. Every so often I read somewhere that pulse makes audio scenario xyz really easy. I try it out and I cannot get any audio samples out to the sound card, period. The only other time I hear about pulse is when I'm telling people to kill it, which ends up fixing all their audio problems. So no thanks to pulse. Meanwhile I can't help but think that Unix already has a security model for talking to devices, it is called enforcing security at open(2). What is bad about letting an app talk to alsa if it needs audio? If you can provide an example, is that not a privilege escalation in alsa that should be fixed? It just strikes me that your article here is a technical solution in search of a problem. Apple did sandboxing so it must be right, huh?
- alexlarsson 12y ago
  > Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I believe this should work: https://github.com/magcius/keylog https://github.com/magcius/keylog > What is bad about letting an app talk to alsa if it needs audio? In general, audio output is not really a problem. However, input is much more problematic. For instance, your app could listen on your microphones and send the data over the network. Permissions on the audio device doesn't work here, especially considering that such permissions are per-user, not per-app. Overall the security model in unix is pretty shit for the desktop. Its all about protecting root or other users from the user. However, if I'm on a single user laptop that is not overly interesting. The much more interesting part is protecting the user from the system. For instance by being able to run a game without it ever having the possibility of reading my personal email or web history.
  - asveikau 12y ago
    > I believe this should work: https://github.com/magcius/keylog https://github.com/magcius/keylog Interesting. Only works if the RECORD extension is enabled, however. Seems some distros have that off by default and have for years.

weland 12y ago

> Is raw audio output necessary? Why does not pulseaudio work? I don't know if this applies to VLC, too, but raw audio output (or something that isn't PulseAudio) is necessary wherever low (or at least constant) latency is required. Edit: oh - now that I look at your username, I believe congratulations are in order re. the subject of this thread :)?

alexlarsson 12y ago
PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/ http://www.freedesktop.org/wiki/Software/PulseAudio/Document... That said, I don't think a video player needs low latencies. It can generally have pretty large buffers.
- riskable 12y ago
  Just to clarify: No one cares if a video player has low-latency audio as long as the audio latency matches the video latency. As in, it totally sucks when the words coming out of an actor's mouth don't line up with the audio. The only place where low-latency matters is real-time encoding situations. For example, video conferencing, composing music, streaming things live, etc but even in those situations "low" is a relative term. Low-latency video conferencing is anything under 200-500ms (depending on who you ask). Low-latency music composition is <20ms (again, depending on who you ask).
  - banjax 12y ago
    Even <20ms is being somewhat generous. I'd just like to see progress TOWARD <20ms on the Android platform. I've been watching this ticket for six years: https://code.google.com/p/android/issues/detail?id=3434 https://code.google.com/p/android/issues/detail?id=3434
- weland 12y ago
  I think VLC also does recording, but I'm certainly in no position to comment on it. I'm not familiar with their codebase and I don't want to lie :). I don't know what PulseAudio considers "very low latency" and there aren't any numbers on that page to indicate it, but in my experience, PA's best latency possibilities are about an order of magnitude away from being useful for any kind of hardcore real-time processing. This isn't a problem as far as PA is concerned since it's not what it was conceived for, but it won't cut it for applications which need that kind of capability. PA also doesn't really provide latency guarantees, either. In fact, it's mentioned on that page: > So in summary: tell PA what latency you want, but program defensively so that you can deal with getting both lower or higher measured latencies. I don't know if that has improved though. The last time I had to poke PulseAudio was a few months before that page's "Last Edited" timestamp. Edit: For what it's worth: I never managed to get PA to consistently keep latency below 25-30 ms, which is at least 10-15 ms away from being adequate for real-time audio processing. I guess it is a cornercase though, and probably outside the Gnome project's interests. Reading the other comments in this thread, I assume VLC's problems with PA aren't related to latency.
- 12y ago

Torgo 12y ago

>once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. Wayland fixes this.

deleted 12y ago
[deleted]

jbk 12y ago

> It all depends on what your goal is. Well, we've seen sandboxes on other desktop platforms (OSX, WinRT, ChromeOS), and so far, they all are horribly limiting. So, I'm making sure the same does not happen on Linux, before we get kicked out of our own platform. > kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. This is not enough, as explained above. > Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things. Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know. > For an example of the later, for webcams see the pulse-video project: https://github.com/wmanley/pulsevideo https://github.com/wmanley/pulsevideo Something using GStreamer in Vala to get indirect access to webcams? I don't see how this could even work: how do you control brightness or other webcam controls from two applications, how do you get direct H26x access with preview synchronized? (And asking someone to use a competitive project to get video input is also a bit rude, but that's beside the subject) > Why does not pulseaudio work? libpulse requires X, as far as I know. > OpenGL access is supported Through Wayland? How do I get YUV surfaces? What about overlay? What about VDPAU/VAAPI? I guess this will get a lot of improvement, because wayland, wl_scaler (et al) are very limited, so far. We'll see how it fares, but from the past interactions, the answers were pretty dismissive; and therefore, I'm not that optimistic about the outcome.

alexlarsson 12y ago
>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. >This is not enough, as explained above. Well, its hard to say that as this kind of stuff is not designed yet. Better to say that the requirements of VLC on the design of this are more complex than just the "allow access to single-picked-file" semantics. Hopefully we can take this into account when we look into the details here. > Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know. Some of these need not necessarily be as complex as you imagine though. They could very well be some kind of thin service that enumerates the real devices and hands over the opened FD to your app after having verified that it is allowed. > libpulse requires X, as far as I know. Libpulse can optionally be built with X, but this is really only used to read back the pulse socket name from the x root property. It works just fine without X (witness the non-X, but pulseaudio using demo in the blog post for instance). OpenGL access is via DRI, but yeah, output to the screen will have to happen via wayland. That could use subsurfaces with YUV surfaces, and it is then up to the compositor to use overlays if possible (i know weston does this for instance). For VDPAU etc, i don't really know.

asveikau 12y ago

> For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I was not under the impression that xscreensaver in particular is vulnerable to such an attack. I would like to see the code. > Is raw audio output necessary? Why does not pulseaudio work? Funny story, I have never gotten pulseaudio to successfully play any audio. Every so often I read somewhere that pulse makes audio scenario xyz really easy. I try it out and I cannot get any audio samples out to the sound card, period. The only other time I hear about pulse is when I'm telling people to kill it, which ends up fixing all their audio problems. So no thanks to pulse. Meanwhile I can't help but think that Unix already has a security model for talking to devices, it is called enforcing security at open(2). What is bad about letting an app talk to alsa if it needs audio? If you can provide an example, is that not a privilege escalation in alsa that should be fixed? It just strikes me that your article here is a technical solution in search of a problem. Apple did sandboxing so it must be right, huh?

alexlarsson 12y ago
> Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I believe this should work: https://github.com/magcius/keylog https://github.com/magcius/keylog > What is bad about letting an app talk to alsa if it needs audio? In general, audio output is not really a problem. However, input is much more problematic. For instance, your app could listen on your microphones and send the data over the network. Permissions on the audio device doesn't work here, especially considering that such permissions are per-user, not per-app. Overall the security model in unix is pretty shit for the desktop. Its all about protecting root or other users from the user. However, if I'm on a single user laptop that is not overly interesting. The much more interesting part is protecting the user from the system. For instance by being able to run a game without it ever having the possibility of reading my personal email or web history.
- asveikau 12y ago
  > I believe this should work: https://github.com/magcius/keylog https://github.com/magcius/keylog Interesting. Only works if the RECORD extension is enabled, however. Seems some distros have that off by default and have for years.