5 ms·

In a recent article on sandboxing in linux [1] it was mentioned that "X11 is impossible to secure". I'm not sure how deep that goes, or whether it's relevant to

• vidarh 12y ago
  Basically, you shouldn't rely on techniques like this to protect you against a malicious app. You can rely on techniques like this as one more step to protect you against stupid mistakes, and to help you keeping configurations etc. isolated and make upgrades easier.
  • eropple 12y ago
    I would say it doesn't even do that, given that you're having to give root-level access to an unprivileged user to do it.
    • vidarh 12y ago
      This conflates two different things. You effectively get root-level access if you are allowed to execute Docker, that is true. But things running in Docker does not have to be given root-level access - you can just as well run things inside Docker as a regular user. I'm not an unprivileged user on any machine I operate in any practical sense, nor are most Linux desktop users, so to me that point is largely moot. That is, even if I'm technically not root most of the time, if I run a malicious app it can relatively easily set up plenty of traps in my home directory to get me to run whatever code it want with elevated privileges sooner or later anyway. So from the outside, having the ability to run Docker does not expose me much more - get my user account, and chances are you get root if you're not completely inept. That doesn't mean it wouldn't be good to get a better/more fine grained privilege model for Docker for other use cases. Inside Docker containers, nothing stops us from having everything run as a regular user, though admittedly many Docker containers errs and runs everything as root often for no good reason (especially given that Docker's port forwarding/mapping means a lot of daemons that otherwise at least wants to start as root - even if it could be avoided - have even less reason to be started as root) But even running as root, assuming an app that isn't malicious, barring me stupidly mounting "/" to a volume in the container, it won't e.g. do things like accidentally deleting [major system directory] (as some app did a while back), even if the app in the container is running as root (which is largely unnecessary, though admittedly done too often, in Docker containers). It also won't barf files all over my filesystem for no good reason. And I won't accidentally expose ports I don't want to expose. Amongst many other things
      • eropple 12y ago
        > I'm not an unprivileged user on any machine I operate in any practical sense, nor are most Linux desktop users, so to me that point is largely moot. That is, even if I'm technically not root most of the time, if I run a malicious app it can relatively easily set up plenty of traps in my home directory to get me to run whatever code it want with elevated privileges sooner or later anyway. I don't know how to say this in a way that isn't snarky, but: be better about your operational security, then. I run all of my Unix machines with the exception of the Mac I don't care about with a user not in /etc/sudoers. That you're tripping yourself up is your own fault. That doesn't excuse this sort of recklessness being advocated by a Docker employee.
• alexlarsson 12y ago
  Basically, all the clients that connect to an Xserver has full trust in each other. You can sniff on any event sent to any client, and send fake events (that are not detectable as fake) to any client, as well as read all the contents of any windows. This essentially means any client can do whatever the user can do. People have tried to make it more secure in various ways (trusted X, selinux X), but it is impossible because so much of the way X does things like DnD, cut-and-paste, window managers, etc that its just not possible to separate clients from each other without the entire thing breaking.
  • SEJeff 12y ago
    Wayland will eventually fix/mitigate this, correct?
    • tmikaeld 12y ago
      Wayland sessions are separated from each other.
• geofft 12y ago
  It's impossible to secure direct, unfiltered access to the X11 protocol: the protocol, by its nature, involves no access controls on who owns what widgets, who gets to inject events, and so forth. There is a "SECURITY" extension to X11, which is what's (often) used when you run ssh -X instead of ssh -Y. It doesn't quite support everything; I fairly often saw things like emacs crash when run with ssh -X. Furthermore, it provides only a single isolation boundary. Every app running with the security extension has access to each other. So, for this sort of use case, the best you could have is that all your Dockerized apps can mess with each other, but not with processes on the host, which isn't quite what you'd hope. There's "security-enhanced X", but basically imagine SELinux applied to each widget on your screen (which is what it is). If you think making SELinux usable and secure is hard, you won't look forward to this. I sketched a design a while ago for doing protocol-level filtering of X where each app effectively lived in its own namespace. Widgets, resources, etc. created by one app are inaccessible to another, because they're not nameable. A middle layer translates each name into a name in a common global namespace, so the X server is unmodified. I think this is doable but a lot of work, especially given how many extensions are in the X protocol. It also doesn't really help you if, say, your OpenGL stack isn't good at isolating one app from another. I think the other promising approach is to use a remote-desktop like solution (like Xpra, or x11vnc, or something) which spawns a separate X11 server, and screen-scrapes it and passes it to the host. You lose a few things like OpenGL, and the overhead might get prohibitive if you run one X server per app, but the isolation is pretty solid.