First fully sandboxed Linux desktop app(blogs.gnome.org)
blogs.gnome.org
First fully sandboxed Linux desktop app
http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
135 comments
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
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
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
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
> 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 :)?
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 :)?
PulseAudio can be very low latency. Here are some docs on how to set this up:
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.
That said, I don't think a video player needs low latencies. It can generally have pretty large buffers.
That link seems to encourage raising the latency, which suggests the needs of people like musicians are not being considered at all. Your use-cases are not the only use cases that exist.
The entire world of music production uses JACK, which got the design right well before PulseAudio even existed. It can provide synchronous operation to prevent drifting between audio tools. I include mplayer2 as one of those tools for s few things. More importantly, JACK guarantees a reliable very, very low latency audio path.
How "low latency" do I mean? Consider that in printed music, while somewhat uncommon, quite a few pieces have been written that use 128th notes. That would be anywhere from ~80ms to ~10ms note lengths, depending on the tempo. Larger latencies mean notes being heard as a different note from what was played, and I keep JACK down to about 5ms latency, and would set it lower if I could afford new hardware. Notes are not the only feature of musinc, and some headroom is needed. Any latencies higher than about 10ms-20ms I would consider broken and unusable.
(Incidentally - I cannot play GuitarHero/RockBand on most TVs either because of horrible latench. A (60Hz) video, a two frame delay is a "miss" on the harder songs. those 16.6ms latencies are nasty regardless which direction the latency is being added)
Beyond that, JACK is a great API. It makes it trivial to do a LOT of the common needs (i.e. "Just give me the audio samples..." or "just let me write new audio data and not have to worry about anything else... such as timing")
The entire world of music production uses JACK, which got the design right well before PulseAudio even existed. It can provide synchronous operation to prevent drifting between audio tools. I include mplayer2 as one of those tools for s few things. More importantly, JACK guarantees a reliable very, very low latency audio path.
How "low latency" do I mean? Consider that in printed music, while somewhat uncommon, quite a few pieces have been written that use 128th notes. That would be anywhere from ~80ms to ~10ms note lengths, depending on the tempo. Larger latencies mean notes being heard as a different note from what was played, and I keep JACK down to about 5ms latency, and would set it lower if I could afford new hardware. Notes are not the only feature of musinc, and some headroom is needed. Any latencies higher than about 10ms-20ms I would consider broken and unusable.
(Incidentally - I cannot play GuitarHero/RockBand on most TVs either because of horrible latench. A (60Hz) video, a two frame delay is a "miss" on the harder songs. those 16.6ms latencies are nasty regardless which direction the latency is being added)
Beyond that, JACK is a great API. It makes it trivial to do a LOT of the common needs (i.e. "Just give me the audio samples..." or "just let me write new audio data and not have to worry about anything else... such as timing")
Raising the latency is what you want in many cases. For instance, the current discussion is about a video player. There is no need for a video player to submit new data every 10ms, because it knows exactly what it will be playing for the next N seconds (depending on the buffer size it uses). Waking up every 10ms just causes more cpu and power use and risks missing the deadline.
Of course, there are cases where you do need lower latencies, such as games where interactive feedback cause the sound to change, or when you pause a movie. In those cases you adjust the latency (possibly temporarily in the case of the pause).
That said, PulseAudio has a different set of requirements and thus design decisions from Jack. It is not meant to be used in music production, but then again, I doubt the music producers will use some sandboxed app to do music production either. So, I don't see the problem here.
Of course, there are cases where you do need lower latencies, such as games where interactive feedback cause the sound to change, or when you pause a movie. In those cases you adjust the latency (possibly temporarily in the case of the pause).
That said, PulseAudio has a different set of requirements and thus design decisions from Jack. It is not meant to be used in music production, but then again, I doubt the music producers will use some sandboxed app to do music production either. So, I don't see the problem here.
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.
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.
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).
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).
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
>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.
Wayland fixes this.
[deleted]
> 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
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.
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
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.
>> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
> 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.
This is not what we understand from your GnomeOS talks and systemd "distributions are obsolete" posts.
>> 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.
> 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.
> 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.
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.
> Experience from OS X and WinRT is that they aren't powerful.
And I'm not suggesting that the current state of things is sufficient.
> What about mkv linked files or .mpc lossless complements? Or cue/bin complements? > What about m3u that have mp3, ogg and flac interleaved?
In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.
Presumably, if I did use those formats, the ability to grant ~/music/.../.{mp3,ogg,flac} or ~/music/ is not a huge step from granting access to *.mp3. If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
We already deal with some of this, with dialogs prompting us about which file types we want to associate with our media players. Reuse and retool those, profit?
And I'm not suggesting that the current state of things is sufficient.
> What about mkv linked files or .mpc lossless complements? Or cue/bin complements? > What about m3u that have mp3, ogg and flac interleaved?
In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.
Presumably, if I did use those formats, the ability to grant ~/music/.../.{mp3,ogg,flac} or ~/music/ is not a huge step from granting access to *.mp3. If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
We already deal with some of this, with dialogs prompting us about which file types we want to associate with our media players. Reuse and retool those, profit?
> In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.
You don't use mkv or playlists with mixed content? You don't use subtitles?
> the ability to grant ~/music/.../.{mp3,ogg,flac} [...] If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
Your first idea is that our codebase is bitrot? Seriously?
> which file types we want to associate with our media players. Reuse and retool those, profit?
And you know, it's been a long time we don't rely on extensions for format detection.
Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
You don't use mkv or playlists with mixed content? You don't use subtitles?
> the ability to grant ~/music/.../.{mp3,ogg,flac} [...] If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.
Your first idea is that our codebase is bitrot? Seriously?
> which file types we want to associate with our media players. Reuse and retool those, profit?
And you know, it's been a long time we don't rely on extensions for format detection.
Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
> You don't use mkv or playlists with mixed content? You don't use subtitles?
No MKV, mp3-only playlists, and then only subtitles I use are those embedded within the .avi / .mp4. I'll certainly admit I'm not VLC power-user.
> Your first idea is that our codebase is bitrot? Seriously?
You've chopped far too much context. I'm assuming your codebase supports neither whitelist in it's current form - reasonable, nothing needs it yet. That is my first idea.
I'm also meaning to imply that you're overstating how difficult it would be, if your codebase did support interacting with the standbox to request .mp3 whitelisting, to request other formats as well. That is my second idea.
My third* idea, at best, is that your codebase has bitrot. This is not me intending to slight you, your project, your contributors, your former contributors, or any of the choices involved. This is not me saying I am better than any of that. This is me, where half of my last job was dealing with bitrot, some caused by my own hand - trying to relate, while trying to identify where such a hypothetical, assumed to be serious problem, would actually lay.
> And you know, it's been a long time we don't rely on extensions for format detection.
You might not, but windows still does. Is this dialog gone?
http://cdn5.howtogeek.com/wp-content/uploads/2013/02/vlc-fil...
> Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
I apologize if it came off that way, and for touching a nerve. But please understand me. The sin you're looking for is Envy, not Arrogance, within me if you've had that leisure - of dealing only with pristine codebases without serious problems.
No MKV, mp3-only playlists, and then only subtitles I use are those embedded within the .avi / .mp4. I'll certainly admit I'm not VLC power-user.
> Your first idea is that our codebase is bitrot? Seriously?
You've chopped far too much context. I'm assuming your codebase supports neither whitelist in it's current form - reasonable, nothing needs it yet. That is my first idea.
I'm also meaning to imply that you're overstating how difficult it would be, if your codebase did support interacting with the standbox to request .mp3 whitelisting, to request other formats as well. That is my second idea.
My third* idea, at best, is that your codebase has bitrot. This is not me intending to slight you, your project, your contributors, your former contributors, or any of the choices involved. This is not me saying I am better than any of that. This is me, where half of my last job was dealing with bitrot, some caused by my own hand - trying to relate, while trying to identify where such a hypothetical, assumed to be serious problem, would actually lay.
> And you know, it's been a long time we don't rely on extensions for format detection.
You might not, but windows still does. Is this dialog gone?
http://cdn5.howtogeek.com/wp-content/uploads/2013/02/vlc-fil...
> Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.
I apologize if it came off that way, and for touching a nerve. But please understand me. The sin you're looking for is Envy, not Arrogance, within me if you've had that leisure - of dealing only with pristine codebases without serious problems.
Then you'd grant access to ~/my-media-collection/ , or to each of the filetypes in your collection.
Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.
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.
And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.
Yeah, double backslash was the first edit I tried :)
[deleted]
> 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?
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?
> 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
> 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.
I believe this should work: 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.
> I believe this should work: 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.
Interesting. Only works if the RECORD extension is enabled, however. Seems some distros have that off by default and have for years.
Instead of sandboxing the entire app, you should use privilege separation inside VLC. Low-risk code would run in processes with higher privileges, while the high-risk code (e.g. the decoders) would run in highly sandboxed processes and communicate with the privileged processes over a simple interface. This is the approach used by security-conscious server apps (e.g. openssh, postfix, dovecot) as well as Google Chrome, and I think it has more promise than trying to sandbox entire apps. Many apps have complex access requirements (much more than the game used as an example in this blog post) and trying to sandbox them will require granting so much privilege that the sandbox becomes almost meaningless.
I'm currently working on converting a PDF viewer to use privilege separation. I'd love to see a media player use privilege separation too. Does VLC currently have pretty clear separation between its various components? Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
I'm currently working on converting a PDF viewer to use privilege separation. I'd love to see a media player use privilege separation too. Does VLC currently have pretty clear separation between its various components? Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
It's a good question. But hard.
> Does VLC currently have pretty clear separation between its various components?
Very clear separation. One of the best, tbh.
> Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
Extremely difficult. We've thought about it.
For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decoders.
The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think).
The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread.
For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).
> Does VLC currently have pretty clear separation between its various components?
Very clear separation. One of the best, tbh.
> Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
Extremely difficult. We've thought about it.
For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decoders.
The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think).
The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread.
For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).
The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder)
Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process.
EDIT, used to use: https://codereview.chromium.org/298443002/
Still, it appears it used this method for a long time, so it seems feasible.
Also, Chrome has multiple video playing paths, including Flash, which is sandboxed, so I don't see the difference. The Flash video has to be decoded in a sandbox. I imagine HTML5 video is sandboxed somehow too.
It is very platform-specific and difficult, and performance is a prime concern, but not impossible.
Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process.
EDIT, used to use: https://codereview.chromium.org/298443002/
Still, it appears it used this method for a long time, so it seems feasible.
Also, Chrome has multiple video playing paths, including Flash, which is sandboxed, so I don't see the difference. The Flash video has to be decoded in a sandbox. I imagine HTML5 video is sandboxed somehow too.
It is very platform-specific and difficult, and performance is a prime concern, but not impossible.
> Why not used shared memory?
Because this is not normal shared memory, this is GPU shared memory. This is hard to port.
Because this is not normal shared memory, this is GPU shared memory. This is hard to port.
Can you not use dma-buf and EXT_image_dma_buf_import?
Maybe, but that's quite not portable, and driver specific, AFAIK.
Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it works with driver-mapped pages too.
Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.
If it's mapped into the CPU address space, then it can be shared. If not, then there is a copy going on and you may as well just do it in the non-sandboxed process, no?
There is no copy. You have a reference to a GPU side buffer, and you want to pass a reference to that buffer to another process, where it will continue to use the GPU to access it.
> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders.
I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing?
In any case, it makes me really happy to know that you've thought about this!
I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing?
In any case, it makes me really happy to know that you've thought about this!
> I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing?
It's GPU allocated memory, so not so sure.
> In any case, it makes me really happy to know that you've thought about this!
If you have ideas, we'd love to work on it, seriously.
It's GPU allocated memory, so not so sure.
> In any case, it makes me really happy to know that you've thought about this!
If you have ideas, we'd love to work on it, seriously.
> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread.
Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way to do process splitting while sharing memory in a "safe" way. (i.e. the recieving side can guarantee that the sending side is not playing silly-buggers with the buffers while you read them).
For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?
Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way to do process splitting while sharing memory in a "safe" way. (i.e. the recieving side can guarantee that the sending side is not playing silly-buggers with the buffers while you read them).
For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?
> For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?
This is not portable, but this is a possible solution for Linux.
But this is far from being ready, which is one of my main point :)
This is not portable, but this is a possible solution for Linux.
But this is far from being ready, which is one of my main point :)
Well, the sandboxing stuff is not ready either. We need work on all levels of the stack to make this stuff work.
I'm curious, have there been bugs in VLC which would allow arbitrary code execution on linux? What about the video player in google chrome?
Yes for both.
Keep in mind that privilege separation does not cover all possible use cases of sandboxing.
Privilege separation is an answer to the question: "I have a program whose authors I trust even though they are fallible, and the program needs to process untrusted data"
In desktop scenarios, I really want an answer to the question: "I have a program whose authors I don't trust, but I want to run it anyway"
For that, you really need full sandboxing; privilege separation is not enough.
Privilege separation is an answer to the question: "I have a program whose authors I trust even though they are fallible, and the program needs to process untrusted data"
In desktop scenarios, I really want an answer to the question: "I have a program whose authors I don't trust, but I want to run it anyway"
For that, you really need full sandboxing; privilege separation is not enough.
If you want raw access to devices, X11, etc, then it is not so simple. The media players I use talk to Pulseaudio, not directly to audio. Various of your needs go pretty much against sandboxing. It's much easier to focus first on applications instead of these needs. For instance, fully sandboxing and X11 won't work anyway.
It seems pretty impossible to create something which: 1) does sandboxing 2) has no limitations on what an application can do
Edit: What I meant is: Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?
It seems pretty impossible to create something which: 1) does sandboxing 2) has no limitations on what an application can do
Edit: What I meant is: Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?
> Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?
Maybe for some, but not for others. You really need to be able to open a file without file opener. Opening optical disks is really important too. I don't get why read-only access to a device poses so much threats but I'm probably missing something.
FYI, so far, libpulse links to x11.
Maybe for some, but not for others. You really need to be able to open a file without file opener. Opening optical disks is really important too. I don't get why read-only access to a device poses so much threats but I'm probably missing something.
FYI, so far, libpulse links to x11.
Low-level access to a device would let you read data from files that you don't have permission to read at the filesystem level.
You can set different permissions for different devices, you are aware of that right? I can say my DVD drive is readable by gid x, but not the partitions on my hard disk... This is already what Linux distros are doing.
Then the media player can read every DVD you put into your drive as long as its running. So you always have to close the media player before inserting a DVD containing private files.
That probably isn't that important for DVDs, but for other devices (e.g. microphone, webcam) it certainly is.
>You really need to be able to open a file without file opener
What if you had read/write access to /home/user/music and /home/user/video ? Once we start adding blanket access like this we would probably need to add a /home/user/secret folder that no application can access unless invited to a specific file by a file opener.
What if you had read/write access to /home/user/music and /home/user/video ? Once we start adding blanket access like this we would probably need to add a /home/user/secret folder that no application can access unless invited to a specific file by a file opener.
Note that you are requiring all of this in the same/single app. Instead it could be broken down into multiple compartmentalized apps, each doing one thing with simple permissions, and all cooperating. For example one app could do the raw device access, but have no other access including networking. Another does networking but no local access. Another is the renderer to video and audio. Another does UI etc.
And how do you share the buffers between the apps?
The desktop environment already has to provide a means of interprocess/component communication, so it gets solved there. You can already see something similar in Chrome where functionality like rendering is done in separate processes.
No it has not. 0-copy shared buffer don't exist yet for most video usecases.
Are you saying it is completely impossible? Or that they haven't done it yet? The former would be a big problem, and the latter is just about the right apis, driver models etc.
> Are you saying it is completely impossible?
Nothing is impossible, this is software. But it's far far far from being ready.
Nothing is impossible, this is software. But it's far far far from being ready.
for such security, you should use something like Qubes OS (https://qubes-os.org/) which uses Xen to sandbox apps into different domains (VMs), and keeps the networking stack in a seperate VM, disk storage in a seperate VM, DE in a seperate VM, etc.
With Wayland and dbus and all the techs going into a modern Linux desktop, it is probably very doable to prompt users when a program tries to open a file with a simple "Application X wants to open file Y in location Z, let it? Yes / No / Allow for all contents of Z / Allow All Locations".
That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it.
> access (and unique probably) to raw devices read-only
I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always".
With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network).
Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour.
I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.
That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it.
> access (and unique probably) to raw devices read-only
I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always".
With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network).
Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour.
I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.
How do they expect you to access the network? Can a web browser or an FTP client be sand boxed in the current scheme?
So far, I am not sure, but I think a flag in the manifest will allow a pure networking access ("Use the host network namespace").
[deleted]
Yeah, if this sandboxing is anything like the Storage Access Framework that Google introduced in Android 4.4, i'll pass...
what's wrong with having a service layer that isn't sandboxed, and an application layer that is?
What's stopping you from running your filesystem and network requests through a local service... you can sandbox all the rendering and other access, and tighten controls on your service interface.
What's stopping you from running your filesystem and network requests through a local service... you can sandbox all the rendering and other access, and tighten controls on your service interface.
Why would you want to sandbox an open source program like VLC? This sort of thing is mostly useful to allow the running of proprietary binaries that could be hostile in some way. You are not going to care that much if you can trust a program not to attack other programs.
Non "hostile," as you put it, software still has bugs. Attackers can use malicious inputs to exploit buggy software.
Unless you personally built software from trusted source with a trusted toolchain, or reverse-engineered and inspected the binary package you are installing, you have no more confidence that your installed binary package is not malicious than any proprietary binary blob. Even presuming the maintainer and packager is not malicious (and why would you trust a random open source maintainer more than a random proprietary maintainer?), there have been cases in the past where repositories have compromised and with malicious packages inserted. These are just the ones we know about. Signatures help but don't solve anything; especially with distributed projects, keys can be compromised in any number of ways. And don't help with malicious actors.
That said, I don't see sandboxing Linux apps as particularly revolutionary. Users, ACLs, and chroots have been around for ages. While not especially sugary, they are pretty effective. For full-on app sandboxing, Android is Linux, and they've been doing this since 2008. The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent. On the server side, "sandboxing" in the form of "separation of privileges" has been standard best practice in the UNIX realm as long as Richard Stallman's beard. This is just not particularly interesting. More interesting to me is what has been done for sandboxing in the browser, most especially Chrome.
Unless you personally built software from trusted source with a trusted toolchain, or reverse-engineered and inspected the binary package you are installing, you have no more confidence that your installed binary package is not malicious than any proprietary binary blob. Even presuming the maintainer and packager is not malicious (and why would you trust a random open source maintainer more than a random proprietary maintainer?), there have been cases in the past where repositories have compromised and with malicious packages inserted. These are just the ones we know about. Signatures help but don't solve anything; especially with distributed projects, keys can be compromised in any number of ways. And don't help with malicious actors.
That said, I don't see sandboxing Linux apps as particularly revolutionary. Users, ACLs, and chroots have been around for ages. While not especially sugary, they are pretty effective. For full-on app sandboxing, Android is Linux, and they've been doing this since 2008. The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent. On the server side, "sandboxing" in the form of "separation of privileges" has been standard best practice in the UNIX realm as long as Richard Stallman's beard. This is just not particularly interesting. More interesting to me is what has been done for sandboxing in the browser, most especially Chrome.
> The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent.
Could you expand on that?
Could you expand on that?
It depends on what you mean by "sandboxing" and "app." But basically, with a browser or mobile app, there's a limited number of functions that you may want to permit an app to access, and it's okay to isolate the rest of the app to its own little world. With desktop apps, you generally want to be able to use apply them broadly to all your user data, or you will quickly be frustrated with them.
Deeper-level sandboxing of splitting the app up into bipartite high and low-security/complexity components, as with the Chrome browser, requires a lot of engineering for the particular application and can't simply be dropped in place on a given off-the-shelf Linux app.
Coarser-level application-specific permissions in the form of AppArmor profiles, installing daemons as their own users with chroots etc, is already available and deployed. The technology to go further with it is already there.
Deeper-level sandboxing of splitting the app up into bipartite high and low-security/complexity components, as with the Chrome browser, requires a lot of engineering for the particular application and can't simply be dropped in place on a given off-the-shelf Linux app.
Coarser-level application-specific permissions in the form of AppArmor profiles, installing daemons as their own users with chroots etc, is already available and deployed. The technology to go further with it is already there.
I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.
Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "Allow" all the time. It would obviously be bad if you get a dialog asking "Application X wants to open file Y. Allow/Deny" whenever an app attemts to access a file. But I don't think that that's the only way to design a sandbox.
For the simple case of opening a file with an app, it could be enough if the app calls a trusted file-chooser outside the sandbox which then returns an opened fd to the file the user chose. Then the user wouldn't even notice that there was a sandbox. Of course that's not enough for all usecases (see some other comments from jbk about VLC).
Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "Allow" all the time. It would obviously be bad if you get a dialog asking "Application X wants to open file Y. Allow/Deny" whenever an app attemts to access a file. But I don't think that that's the only way to design a sandbox.
For the simple case of opening a file with an app, it could be enough if the app calls a trusted file-chooser outside the sandbox which then returns an opened fd to the file the user chose. Then the user wouldn't even notice that there was a sandbox. Of course that's not enough for all usecases (see some other comments from jbk about VLC).
> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.
You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their respective media files in your home folder, right? And you want might want them to be able to actually work together, right? Such as opening a file you downloaded in the browser. Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
What you seem disturbed by is that one application can access configuration and state data belonging to another application. Because they are just files, belonging to the same user. Well, I suppose if such a policy made you feel better, you could always change the AppArmor profiles to only allow an application to modify its own dotfiles, dotdirectory, e.g., fooapp can't touch ~/.* except ~/.fooapp. That's not a terrible idea, although if you are so distrustful of it to begin with and still want to run it you should probably sandbox it in its own filesystem altogether. And this will break some interoperability.
You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their respective media files in your home folder, right? And you want might want them to be able to actually work together, right? Such as opening a file you downloaded in the browser. Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
What you seem disturbed by is that one application can access configuration and state data belonging to another application. Because they are just files, belonging to the same user. Well, I suppose if such a policy made you feel better, you could always change the AppArmor profiles to only allow an application to modify its own dotfiles, dotdirectory, e.g., fooapp can't touch ~/.* except ~/.fooapp. That's not a terrible idea, although if you are so distrustful of it to begin with and still want to run it you should probably sandbox it in its own filesystem altogether. And this will break some interoperability.
Yes, I want applications to be able to open files and to work together, but only if that's needed to achive what I want them to do. LibreOffice should be able to open (and read from and write to) any .odt-file that I want to edit. But since to do that it doesn't need to have access to my browsing history, I don't want it to have access to that. Is it weird that I want that?
> Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
Yes, it does. If the file chooser is inside the application, it needs to be able to open the chosen file, i.e. an arbitrary path, at any time. If the file chooser is outside the sandbox, the application only gets the open fd and can't open files itself (open(2) would simply fail). That is a huge difference!
> What you seem disturbed by is that one application can access configuration and state data belonging to another application.
Yes, I am disturbed by that and I am certainly not alone. There simply is no reason why it should be that way, apart from backwards-compatibility. Why should I have to trust the hundreds of millions of lines of code in all the applications on my machine, if such a huge amount of trust is not necessary to achive the desired outcome?
And sure, application sandboxing can already be achived with AppArmor or SELinux (or a multitude of other systems), but it requires manual work (afaik no major distribution comes with this out of the box) and (as you correctly write) it breaks interoperability. The goal of this "Gnome app sandbox" isn't to be the first application sandbox, but to provide the possibility to enable this by default for certain applications and to keep interoperability. That last part is mostly a research project, so I don't expect this to be finished any time soon.
> Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.
Yes, it does. If the file chooser is inside the application, it needs to be able to open the chosen file, i.e. an arbitrary path, at any time. If the file chooser is outside the sandbox, the application only gets the open fd and can't open files itself (open(2) would simply fail). That is a huge difference!
> What you seem disturbed by is that one application can access configuration and state data belonging to another application.
Yes, I am disturbed by that and I am certainly not alone. There simply is no reason why it should be that way, apart from backwards-compatibility. Why should I have to trust the hundreds of millions of lines of code in all the applications on my machine, if such a huge amount of trust is not necessary to achive the desired outcome?
And sure, application sandboxing can already be achived with AppArmor or SELinux (or a multitude of other systems), but it requires manual work (afaik no major distribution comes with this out of the box) and (as you correctly write) it breaks interoperability. The goal of this "Gnome app sandbox" isn't to be the first application sandbox, but to provide the possibility to enable this by default for certain applications and to keep interoperability. That last part is mostly a research project, so I don't expect this to be finished any time soon.
A file chooser outside the application is safer if the sandbox enforces that only selected files are opened. Of course I want the app to be able to read files I told it to open, but it shouldn't be able to access files I haven't selected.
How about the sub files with the same name of the video file you selected? Some players open them automatically and it's very convenient. I'm sure there are other cases like that.
Just because it can't cover every single case and application doesn't mean it isn't worth using it for those where it fits. It's an interesting question how far one would want to go to support these special cases, because doing so adds complexity to both code and the things the user has to understand, but the nice thing with an open system is: we don't have to use it for applications that don't fit the model very well or can allow exceptions where needed.
You don't need a different file chooser widget for that. You can use AppArmor or other MAC systems.
Can you really? With the external file chooser, the app has no access to user files before a file is picked, then has access to only this one particular file, and after it is closed returns to no access again.
How would you do this with a generic MAC system without using additional software that dynamically changes the MAC policy and/or relabels files and without bothering the user?
How would you do this with a generic MAC system without using additional software that dynamically changes the MAC policy and/or relabels files and without bothering the user?
Don't think of it like, "I need to protect against hacking" think of it like, "I need to make sure processes cannot control each other unless explicitly allowed to do so."
Hypothetical: A vulnerability in Chrome could allow a remote attacker the ability to read/write arbitrary files on your filesystem. /tmp/.X11-unix/X0 for example. This could let them cause all sorts of havoc on your X11 display including controlling/compromising other running programs (and capturing your keystrokes).
If Chrome were sandboxed as described in the article such an attack would not be possible without first breaking out of the sandbox.
Hypothetical: A vulnerability in Chrome could allow a remote attacker the ability to read/write arbitrary files on your filesystem. /tmp/.X11-unix/X0 for example. This could let them cause all sorts of havoc on your X11 display including controlling/compromising other running programs (and capturing your keystrokes).
If Chrome were sandboxed as described in the article such an attack would not be possible without first breaking out of the sandbox.
Media players are rather large programs that users feed lots of untrusted data (gigabytes of pirated movies/tv shows/porn from suspect sources etc) into. All it takes is one exploitable bug in your media player of choice (or more likely, in a hardware-accelerated codec it uses) and one maliciously malformed video for your home directory to be nuked, keylogger to be installed, or worse.
>they refuse blankly, saying that my "use case is irrelevant and dangerous".
Because it's not like anyone uses media players in the real world.
Seriously, WHAT?
Because it's not like anyone uses media players in the real world.
Seriously, WHAT?
While I'll admit that my personal project, subuser.org isn't yet at the stage of 100% sandboxed, this title is excedingly misleading. There are lots of projects that have done this allready: http://www.jann.cc/2014/09/06/sandboxing_proprietary_applica..., https://github.com/Kagami/kagome
The title is a bit hyperbolic, true. There have been various ways to try to contain desktop apps over the years. But I wouldn't call them "apps" really, they may get the sandboxing aspects down, but they don't have the simple-to-install, well-integrated behaviour that you'd want for something like an "app" system. Most of them basically run the app in its own VNC or Xserver instance, with zero interaction with the rest of the session.
Sounds like a browser to me. FTFY:
* Is independent of the host distribution
* Has no access to any system or user files other than the ones from the runtime and application itself
* Has no access to any hardware devices (GL rendering supported)
* Has restricted network access
* Can’t see any other processes in the system
* Can only get input via standard APIs
* Can only show graphics via DOM/Canvas/WebGL/SVG/MathML
* Can only output audio via Audio Tags/Web Audio/MSE
* plus more sandboxing details
* Is independent of the host distribution
* Has no access to any system or user files other than the ones from the runtime and application itself
* Has no access to any hardware devices (GL rendering supported)
* Has restricted network access
* Can’t see any other processes in the system
* Can only get input via standard APIs
* Can only show graphics via DOM/Canvas/WebGL/SVG/MathML
* Can only output audio via Audio Tags/Web Audio/MSE
* plus more sandboxing details
This is actually quite similar to using LXC containers to run GUI apps. Something like Wine would be a good candidate to run in a container, perhaps others too. And you can use both privileged and unprivileged containers for this.
I have a guide on running accelerated GUI apps in both privileged and unprivileged containers: http://www.flockport.com/run-gui-apps-in-lxc-containers and here's one more by Stephane Graber, lead developer of LXC using only unprivileged containers: https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...
I have a guide on running accelerated GUI apps in both privileged and unprivileged containers: http://www.flockport.com/run-gui-apps-in-lxc-containers and here's one more by Stephane Graber, lead developer of LXC using only unprivileged containers: https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...
I have mixed feelings on the idea of sandboxed apps.
On the one hand, I want to be able to run untrusted applications safely. And in a larger sense, I think that it might be a hopeless endeavor to try to get users to only run trustworthy applications on their machines.
On the other hand, I want to have full access to my system, and sometimes that means having full access to it through applications (jbk's VLC use case is a good example of that). And sandboxes are far from perfect (this may improve, but right now existing sandboxes still have lots of holes). Sandboxes may be just security theater at this point (although as I said, this might change).
On the one hand, I want to be able to run untrusted applications safely. And in a larger sense, I think that it might be a hopeless endeavor to try to get users to only run trustworthy applications on their machines.
On the other hand, I want to have full access to my system, and sometimes that means having full access to it through applications (jbk's VLC use case is a good example of that). And sandboxes are far from perfect (this may improve, but right now existing sandboxes still have lots of holes). Sandboxes may be just security theater at this point (although as I said, this might change).
>> we have to use Wayland instead of X11, because X11 is impossible to secure.
Yet X11 was designed in the prime example world of a mult-user OS, UNIX. Hmm.
>> We also need to use kdbus to allow desktop integration that is properly filtered at the kernel level.
Didn't I read an article on HN recently talking about a vulnerability in Windows and the subject of too close a relationship between the kernel and the end user graphics came up?
Yet X11 was designed in the prime example world of a mult-user OS, UNIX. Hmm.
>> We also need to use kdbus to allow desktop integration that is properly filtered at the kernel level.
Didn't I read an article on HN recently talking about a vulnerability in Windows and the subject of too close a relationship between the kernel and the end user graphics came up?
This isn't about isolating users from each other, but isolating different applications running as the same user from each other. X11 (and Unix itself) was not designed to do this.
Also, kdbus has nothing to do with graphics.
Also, kdbus has nothing to do with graphics.
How hard would it be to make something like:
This program wants to access your camera, mike, //home/personal, connect to irc://botnet.com, and install these dependencies: spyware1, 2, 3 Are you sure you want to install/run [insert innocent program]?
I think that would be an better option then sand-boxing everything.
Is it even possible for the OS to know if a program is using the webcam?
This program wants to access your camera, mike, //home/personal, connect to irc://botnet.com, and install these dependencies: spyware1, 2, 3 Are you sure you want to install/run [insert innocent program]?
I think that would be an better option then sand-boxing everything.
Is it even possible for the OS to know if a program is using the webcam?
So a seriously limiting concept from mobile/web world is making it into Linux as well? Soon we won't be able to do anything with our computers, but we will be "perfectly safe". Everything I dislike about iOS is now becoming mainstream. Disclaimer - I wrote a book about cryptology including TPM, secure boot loaders, PKI, etc. another one about 3D graphics and am very aware of the issues and trade offs. But sandboxing is a charming but ultimately silly solution that ultimately removes any capability from the hands of users and slows everything down - it already negatively affects graphics performance of browsers (tainted canvas anyone? how long would WebGL shader hack to bypass this work until we are forced to accept 100 pixels/second performance with sandboxing?). There are even rumors that Skylake is going to be slower and more power hungry than Broadwell due to SGX (we will see soon I guess). Is it really worth it?
The cargo-culting continues.
Slightly off topic but what happened to the 'Android as Linux desktop' initiatives?
Y U No Docker ?
The future is here! Maybe the lack of a heavily regulated, but ultimately non-curated aggregation of low quality application that safely do nothing has been holding back Linux on the desktop all these years.
P.S.: systemd now allows logging in via your Facebook account on every machine, per default since Ubuntu Timid Tamandu!
P.S.: systemd now allows logging in via your Facebook account on every machine, per default since Ubuntu Timid Tamandu!
In the light of the NSA hacking revelations, we should recognize that the systems we're using are fundamentally insecure. With Linux, we should be able to improve security while maintaining user control. I think this is a step in the right direction.
To be fair, this has exactly zero effect on the NSA hacking your machine, especially if the hard disk firmware is compromised.
Only if the firmware is compromised before you install the OS. It adds a significant hurdle to any malware gaining write access to your hard drive's firmware.
This is not really true
https://www.usenix.org/legacy/events/atc10/tech/full_papers/...
which was turned into
https://www.google.com/patents/US8589947
https://www.usenix.org/legacy/events/atc10/tech/full_papers/...
which was turned into
https://www.google.com/patents/US8589947
chroot existed before 11 mag 2010
apparently you think usenix atc is unaware of chroot as well :)
better later than never
I've been working on getting web-based X11 working for a while now...
http://youtu.be/vca13X1TpIw
It works very well but I can't release it yet because there's an underlying problem and the author of this article pointed it out very clearly:
> because X11 is impossible to secure
So imagine the scenario: You want to have a single server that hosts desktop environments for multiple users over the web. X11 is multi-user! No problem, right? Wrong.
Your little web server daemon is going to run as some user. Let's say that user is root to keep things simple. So now your root user needs to spin up an X11 server for each user (so their sessions are separate). But that won't work so well because the X11 servers will all be running as the same user (root). This means that each user can mess with each other's applications, log their keystrokes, etc.
So what do you do? Well, you can just create random, one-time user accounts in /etc/passwd and spin up X11 using those accounts but now your little daemon has to run as root. Also, you now have to keep track of and maintain not just all those temporary users but all the files owned by those users. You also need to keep track of which user had what account and when (for auditing purposes). You also have to worry about UID conflicts (especially with external systems) and some other less common scenarios (e.g. LDAP integration with sudo).
Another option would be to give each user their own container and run X11 inside of that. Except now the application can't get access to OpenGL acceleration and shared memory access (so your little deamon can capture the screen) becomes complicated. Then there's the fact that if you want to give the users access to more applications those applications will need to be installed inside each user's container. You can do some tricks with mounts in order to work around that problem somewhat but it's complicated. REALLY complicated!
For now I've decided to just assume the daemon will be running as a single user (doesn't matter which one) while I work on some other things (e.g. improving audio support) but very soon I'm going to have to come back to the multi-user security problem. It's not easy to solve.
The way X11 was engineered just assumes that each user has their own processes and if you do have multiple users all their applications will be running under different accounts.
http://youtu.be/vca13X1TpIw
It works very well but I can't release it yet because there's an underlying problem and the author of this article pointed it out very clearly:
> because X11 is impossible to secure
So imagine the scenario: You want to have a single server that hosts desktop environments for multiple users over the web. X11 is multi-user! No problem, right? Wrong.
Your little web server daemon is going to run as some user. Let's say that user is root to keep things simple. So now your root user needs to spin up an X11 server for each user (so their sessions are separate). But that won't work so well because the X11 servers will all be running as the same user (root). This means that each user can mess with each other's applications, log their keystrokes, etc.
So what do you do? Well, you can just create random, one-time user accounts in /etc/passwd and spin up X11 using those accounts but now your little daemon has to run as root. Also, you now have to keep track of and maintain not just all those temporary users but all the files owned by those users. You also need to keep track of which user had what account and when (for auditing purposes). You also have to worry about UID conflicts (especially with external systems) and some other less common scenarios (e.g. LDAP integration with sudo).
Another option would be to give each user their own container and run X11 inside of that. Except now the application can't get access to OpenGL acceleration and shared memory access (so your little deamon can capture the screen) becomes complicated. Then there's the fact that if you want to give the users access to more applications those applications will need to be installed inside each user's container. You can do some tricks with mounts in order to work around that problem somewhat but it's complicated. REALLY complicated!
For now I've decided to just assume the daemon will be running as a single user (doesn't matter which one) while I work on some other things (e.g. improving audio support) but very soon I'm going to have to come back to the multi-user security problem. It's not easy to solve.
The way X11 was engineered just assumes that each user has their own processes and if you do have multiple users all their applications will be running under different accounts.
I use this all the time these days https://github.com/kanaka/noVNC
related to what you are trying to do?
related to what you are trying to do?
noVNC is similar to what I'm working on, yes. Except it implements the VNC protocol in JavaScript which isn't the greatest when it comes to bandwidth efficiency. It's also not very flexible; it only works when sharing an entire desktop (not individual applications or windows).
As an example of the efficiency difference, when viewing an entire desktop with a single terminal application running 'top' Gate One used up 1/10th the amount of bandwidth as noVNC when I last performed benchmarking (I had them both displaying the same exact desktop; both Gate One and novnc running simultaneously).
Also, noVNC CPU utilization goes through the roof if you try to do something like play back a video. When playing back a video inside Gate One the gateone.py process only eats up about 8% of a single core of my laptop's i7 (4th gen). That's with loads of debugging enabled (I tested it just now with SMPlayer playing Big Buck Bunny somewhere at ~1024x768 resolution).
My benchmark goal is to be able to play Minecraft @30fps (~1024x768) remotely using an AWS/Rackspace/OpenStack server. I've already achieved that except the audio delay sucks (~2 seconds) so that's what I'm currently working on (had to write my own Opus/WebM audio encoder).
As an example of the efficiency difference, when viewing an entire desktop with a single terminal application running 'top' Gate One used up 1/10th the amount of bandwidth as noVNC when I last performed benchmarking (I had them both displaying the same exact desktop; both Gate One and novnc running simultaneously).
Also, noVNC CPU utilization goes through the roof if you try to do something like play back a video. When playing back a video inside Gate One the gateone.py process only eats up about 8% of a single core of my laptop's i7 (4th gen). That's with loads of debugging enabled (I tested it just now with SMPlayer playing Big Buck Bunny somewhere at ~1024x768 resolution).
My benchmark goal is to be able to play Minecraft @30fps (~1024x768) remotely using an AWS/Rackspace/OpenStack server. I've already achieved that except the audio delay sucks (~2 seconds) so that's what I'm currently working on (had to write my own Opus/WebM audio encoder).
yes, vnc is not made for video (or audio, but that's obvious). a decade ago the lab I was part of was working on that issue.
http://systems.cs.columbia.edu/projects/thinc/
maybe something here is of interest to you (code is probably way outdated though)
http://systems.cs.columbia.edu/projects/thinc/
maybe something here is of interest to you (code is probably way outdated though)
Do these sandboxes requiring bundling all the necessary dependencies a la Windows applications? I sure hope not.
I am not sure why Linux people tend to think this is bad. It is how you ship robust software that doesn't break. Linux "solves" this issue by having all kinds of things break all the time and just accepting that breakage and saying "no really things usually work fine".
The main argument against this kind of bundling (apart from higher disk usage) is about security updates of libraries. E.g. if many applications ship their own copy of OpenSSL and another vulnerability is discovered, you have to update every application individually. And it is unlikely that all developers/vendors will provide such updates fast enough.
But if all applications use the same OpenSSL that is managed by dpkg+apt (or something similar), a single update will fix all applications.
Personally, I don't think that this problem can be solved without losing the advantages of bundling (robustness, reproducability, binary portability to other distributions).
But if all applications use the same OpenSSL that is managed by dpkg+apt (or something similar), a single update will fix all applications.
Personally, I don't think that this problem can be solved without losing the advantages of bundling (robustness, reproducability, binary portability to other distributions).
Right, but there's a difference between things that the OS is expected to provide (OpenSSL, GTK, etc) which the app should not bundle, and things like libpng which the app basically should bundle.
e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng.
Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the app.
e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng.
Pretty much the whole point of an OS is to provide a guaranteed stable base. Anything that isn't guaranteed or stable should be bundled with the app.
If libpng has a new vulnerability discovered, how do you make sure it is fixed in all the apps that bundle it?
http://www.cvedetails.com/vulnerability-list/vendor_id-7294/...
http://www.cvedetails.com/vulnerability-list/vendor_id-7294/...
GTK indirectly depends on libpng, so that probably wasn't the best example ;)
The thing is that Linux distributions traditionally don't make any difference between the OS and apps. Everything is split into relatively small packages. Like everything this model has some advantages (e.g. security updates) but also some disadvantages (it's harder to distribute/install software outside the distribution).
The thing is that Linux distributions traditionally don't make any difference between the OS and apps. Everything is split into relatively small packages. Like everything this model has some advantages (e.g. security updates) but also some disadvantages (it's harder to distribute/install software outside the distribution).
I would argue that you shouldn't bundle any libraries at all. As a package maintainer, I get real annoyed at projects that bundle things like libpng and don't provide an easy way to use an already built version.
>It is how you ship robust software that doesn't break.
It's how you ship 1000 different versions of the same library and have no idea what to do when they need to be upgraded. It's just a terrible way to manage a system. Easier doesn't mean better.
It's how you ship 1000 different versions of the same library and have no idea what to do when they need to be upgraded. It's just a terrible way to manage a system. Easier doesn't mean better.
Seems like Linus agrees with you to an extent. He thinks it is sad to have to statically link libraries and create huge binaries but it is what you currently have to do to ensure things don't break.
Be aware of typical Linus swearing: https://www.youtube.com/watch?v=5PmHRSeA2c8#t=358
Be aware of typical Linus swearing: https://www.youtube.com/watch?v=5PmHRSeA2c8#t=358
In my understanding you can just (read-only) bind-mount the necessary libraries into the sandbox, ship your own, or do a combination of the former two.
bind-mounting and/or symlinks are good ways to go. That way there isn't unnecessary duplication.
I think this blog post highlights my beef with going ultra secure and not trusting the user.
security will stifle application innovation. Making cool things hard, and awesome things impossible.
security will stifle application innovation. Making cool things hard, and awesome things impossible.
It's not about "not trusting the user", but about the user not having to trust the author of the application.
The result is still the same though.
No. Why would it?
The user can still grant full access to the machine to applications they trust (like they do now).
In fact, the traditional Unix security model (root vs. regular users) was about "not trusting the user" and securing the machine from the user. This "new" kind of sandbox is about the user being able to apply different levels of trust to different applications.
I can see this being useful for running proprietary and non free software. However, we should strive for all software to be free software instead. Because if I download free software, I have the community of developers to vouch for it. If I download proprietary software, I can't really trust it.
My answer to that is "heartbleed". It is irrelevant if you trust the developers - sometimes those developers will make mistakes. Sometimes those mistakes will be serious.
The less privileges your applications run with, the less likely it will be that exploits will affect you.
The less privileges your applications run with, the less likely it will be that exploits will affect you.
You think you can trust the authors of every free software package to have kept out all security flaws? That's a mighty happy world you live in.
As a programmer who makes his living selling software I'm not particularly keen on "all software to be free".
Do you run everything as root? Why not, don't you trust the user?
want this on embedded devices...bundling apps on embedded linux is real pain.
I don't think this will help you. It sounds more like you need something like buildroot or 0install.
well. i want to do some testing on a legacy app. The app runs fine on old veriosn of firefox and old OS but i want to try it on a recent distribution and remove firefox dependancy as a next step. Isn't it fits with sandboxing way of app development.?
Indeed, for a complete media player, I need:
- access to files not directly opened by the user (playlists, MKV, DCP, MXF),
- access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB),
- direct access to raw audio output,
- access to X11 for YUV output, or at least a direct OpenGL context,
- access to network.
For access to files and network, there seemed to be a solution with a manifest to get $home access; for audio, a solution might come with kdbus and pulseaudio; but for the others, they refuse blankly, saying that my "use case is irrelevant and dangerous".
I hope this will evolve (maybe it already has), but so far, it's a bit hard to make a complete media player, tbh.