6 ms·

> 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

by 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.
- jbk 12y ago
  > Hopefully we can take this into account when we look into the details here. This is all I'm asking, and not the usual "I don't care about your usecase, you should just use GStreamer" that we get from the Gnome/RedHat/Systemd team.
- greggman 12y ago
  Maybe I'm missing it but I don't see how DRI is really sandboxing OpenGL. Note: I helped write the OpenGL sandbox in Chrome and it's certainly possible I don't know the details of DRI enough to understand how it sandboxes but I do know what we had to do to sandbox OpenGL in Chrome, that includes re-writing shaders since we can't trust the driver, clearing buffers since OpenGL doesn't and so you can read other processes' data, and many other things and as far as I can tell DRI isn't doing things like that.
  - lunixbochs 12y ago
    I'm pretty sure DRI doesn't do anything special to the OpenGL calls, so they just get punted into the scary binary client library from your GPU vendor.
  - alexlarsson 12y ago
    At the moment we grant all of /dev/dri, but long term we want only the render nodes accessible. That gives us no modesetting or DRM master capabilities, only rendering. It is true though that the drivers could very well have leaks in them, but the userspace sandbox is not the place to fix that, it is the drivers themselves. The intent is for the dri driver APIs to give guarantees about client separation, but I'm sure it needs work.
    - greggman 12y ago
      The drivers will never be fixed. Chrome doesn't trust them. It's not in their interest to fix them since sales are determined by performance not by security.
ANTSANTS 12y ago
Yeah, the possibility of a "gatekeeper effect" is what's worrisome here. There's no way you can anticipate everything a user might want to do with their computer, so while opt-in sandboxing can only help, mandatory sandboxing could stifle the creativity of developers who must go through a gatekeeper (even a benevolent one) any time they want to ship a program that uses hardware or software abstractions in some unforeseen way. Or alternatively, Joe User goes "[grumble grumble] guess I gotta delete that dang PulsePolicyD that's keepin' me from runnin' muh binaries [copies and pastes the first command found when googling "how i run X" into shell]" and it's all for naught.
MaulingMonkey 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. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as I'm concerned.
- wlesieutre 12y ago
  Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.
  - wlesieutre 12y ago
    That actually took a couple of edits with inconsistent results. Sometimes it actually prints the backslash? \* \*. And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.
    - MaulingMonkey 12y ago
      Yeah, double backslash was the first edit I tried :)
    - deleted 12y ago
      [deleted]
- jbk 12y ago
  > If the file chooser is powerful enough, couldn't it be? Experience from OS X and WinRT is that they aren't powerful. > I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 What about mkv linked files or .mpc lossless complements? Or cue/bin complements? What about m3u that have mp3, ogg and flac interleaved? It's not that simple.
  - gknoy 12y ago
bkor 12y ago
> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform. To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll take some time because there's a lot of things to work out (e.g. relying on Wayland, kdbus, change Pulseaudio to use kdbus, etc). A user should have control on what an application can do, but that's something new and user might highly prefer such applications (e.g. not allowing an application to just modify ~/.bashrc and adding some evil sudo alias if it feels like it). IMO at most you'd have some package software which shows for VLC: "unrestricted access". The intention is to offer more security where possible to the user while at the same time it's not too difficult for the developer.
- jbk 12y ago
  > To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This is not what we understand from your GnomeOS talks and systemd "distributions are obsolete" posts.

by jbk 12y ago

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.

jbk 12y ago
> Hopefully we can take this into account when we look into the details here. This is all I'm asking, and not the usual "I don't care about your usecase, you should just use GStreamer" that we get from the Gnome/RedHat/Systemd team.
greggman 12y ago
Maybe I'm missing it but I don't see how DRI is really sandboxing OpenGL. Note: I helped write the OpenGL sandbox in Chrome and it's certainly possible I don't know the details of DRI enough to understand how it sandboxes but I do know what we had to do to sandbox OpenGL in Chrome, that includes re-writing shaders since we can't trust the driver, clearing buffers since OpenGL doesn't and so you can read other processes' data, and many other things and as far as I can tell DRI isn't doing things like that.
- lunixbochs 12y ago
  I'm pretty sure DRI doesn't do anything special to the OpenGL calls, so they just get punted into the scary binary client library from your GPU vendor.
- alexlarsson 12y ago
  At the moment we grant all of /dev/dri, but long term we want only the render nodes accessible. That gives us no modesetting or DRM master capabilities, only rendering. It is true though that the drivers could very well have leaks in them, but the userspace sandbox is not the place to fix that, it is the drivers themselves. The intent is for the dri driver APIs to give guarantees about client separation, but I'm sure it needs work.
  - greggman 12y ago
    The drivers will never be fixed. Chrome doesn't trust them. It's not in their interest to fix them since sales are determined by performance not by security.

ANTSANTS 12y ago

Yeah, the possibility of a "gatekeeper effect" is what's worrisome here. There's no way you can anticipate everything a user might want to do with their computer, so while opt-in sandboxing can only help, mandatory sandboxing could stifle the creativity of developers who must go through a gatekeeper (even a benevolent one) any time they want to ship a program that uses hardware or software abstractions in some unforeseen way. Or alternatively, Joe User goes "[grumble grumble] guess I gotta delete that dang PulsePolicyD that's keepin' me from runnin' muh binaries [copies and pastes the first command found when googling "how i run X" into shell]" and it's all for naught.

MaulingMonkey 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. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as I'm concerned.

wlesieutre 12y ago
Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.
- wlesieutre 12y ago
  That actually took a couple of edits with inconsistent results. Sometimes it actually prints the backslash? \* \*. And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.
  - MaulingMonkey 12y ago
    Yeah, double backslash was the first edit I tried :)
  - deleted 12y ago
    [deleted]
jbk 12y ago
> If the file chooser is powerful enough, couldn't it be? Experience from OS X and WinRT is that they aren't powerful. > I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 What about mkv linked files or .mpc lossless complements? Or cue/bin complements? What about m3u that have mp3, ogg and flac interleaved? It's not that simple.
- gknoy 12y ago

bkor 12y ago

> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform. To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll take some time because there's a lot of things to work out (e.g. relying on Wayland, kdbus, change Pulseaudio to use kdbus, etc). A user should have control on what an application can do, but that's something new and user might highly prefer such applications (e.g. not allowing an application to just modify ~/.bashrc and adding some evil sudo alias if it feels like it). IMO at most you'd have some package software which shows for VLC: "unrestricted access". The intention is to offer more security where possible to the user while at the same time it's not too difficult for the developer.

jbk 12y ago
> To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This is not what we understand from your GnomeOS talks and systemd "distributions are obsolete" posts.