Re: [Discuss] sandboxing web browsers
On 6/22/2015 12:19 PM, John Abreau wrote: That fact that an incompetent buffoon can misuse a tool to create badly designed software does not mean that it's impossible for a skilled programmer to use the tool correctly to create well-designed software. Agreed. But what I've been seeing from Docker containers is a proliferation of incompetence and laziness. It's the other side of your argument's coin. Docker containers are essentially black boxes. They don't need to be opaque but they're typically treated that way. This lets lazy and incompetent programmers get away with things that would be unacceptable with traditional deployment methods. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
So your point is that some developers create piss-poor Docker deployments, and therefore Docker is a piece of shit?. That logic could be applied to any development system. I've seen plenty of piss-poor coding done in perl, python, C, Fortran, and every other language I've ever reviewed. That fact that an incompetent buffoon can misuse a tool to create badly designed software does not mean that it's impossible for a skilled programmer to use the tool correctly to create well-designed software. On Mon, Jun 22, 2015 at 10:40 AM, Richard Pieri richard.pi...@gmail.com wrote: On 6/21/2015 10:38 PM, Tom Metro wrote: The Docker daemon runs as root. If the non-privileged user starting FF is put in the docker group and allowed to start any container, then yes, they have root. If instead a SetUID script or sudo rule is used to launch a specific container, which does not launch a root shell, then the resulting container and FF process won't have root privileges. Docker requires root to initialize containers. It's how Docker was designed. It's a known design flaw and the Docker folks have gone on record stating that they don't intend to fix it. So, if you're going to let me start Docker containers then I will be able to elevate myself to root on the host. The only way to stop me is not to let me start Docker containers at all. Docker does not work perfectly well in the first place in my experience. That may very well be your experience. But some of us use it daily and find that it does the intended job. FSVO intended. My experience is that developers have been using Docker to rationalize piss-poor deployment practices. It doesn't matter to them if their run time environments are utter hell for users to recreate, just put it all in a container and copy the hell everywhere. One most egregious example that I've had to deal with, a project called ShareLaTeX, their environments are so bad that their containers are the only supported way of deploying. So bad that their containers don't work outside of their own environments. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss -- John Abreau / Executive Director, Boston Linux Unix Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
On 6/21/2015 10:38 PM, Tom Metro wrote: The Docker daemon runs as root. If the non-privileged user starting FF is put in the docker group and allowed to start any container, then yes, they have root. If instead a SetUID script or sudo rule is used to launch a specific container, which does not launch a root shell, then the resulting container and FF process won't have root privileges. Docker requires root to initialize containers. It's how Docker was designed. It's a known design flaw and the Docker folks have gone on record stating that they don't intend to fix it. So, if you're going to let me start Docker containers then I will be able to elevate myself to root on the host. The only way to stop me is not to let me start Docker containers at all. Docker does not work perfectly well in the first place in my experience. That may very well be your experience. But some of us use it daily and find that it does the intended job. FSVO intended. My experience is that developers have been using Docker to rationalize piss-poor deployment practices. It doesn't matter to them if their run time environments are utter hell for users to recreate, just put it all in a container and copy the hell everywhere. One most egregious example that I've had to deal with, a project called ShareLaTeX, their environments are so bad that their containers are the only supported way of deploying. So bad that their containers don't work outside of their own environments. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
On 6/21/2015 12:59 PM, Tom Metro wrote: How about running FF in a Docker container, so not only do you get the privilege isolation from the different user, but also process isolation and file system isolation. It would be the next best thing to running it in a full VM, yet without the overhead. Which in fact /reduces/ overall system security. Starting a Docker container requires root. This means users who would not otherwise be doing things as root must now be root to start their browsers. Does anyone else see the problem inherent in this? Actually, at least one does: https://fosterelli.co/privilege-escalation-via-docker.html That's not even beginning to touch on the problems with updating the browsers. Because one doesn't update applications in a Docker container; one updates the whole container. So, what happens to custom configurations and add-ons and bookmarks and passwords and auto-fill forms and so forth? Less security and less convenience? Sign me up? No thank you. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
Mike Small wrote: What about creating a second, less privileged user for running firefox... How about running FF in a Docker container, so not only do you get the privilege isolation from the different user, but also process isolation and file system isolation. It would be the next best thing to running it in a full VM, yet without the overhead. CPU and RAM limits could similarly be applied. Of course all that isolation will increase inconvenience. Assuming you ever up/download things with your browser, you'll need to set up a Docker volume that maps to something in your host file system so you can get files in/out of the container. ...I run firefox as my main user with no plugins. Sadly, with almost any attempt at improving browser security, like disabling cookies or JavaScript, you end up having to have a 2nd unadulterated browser (or profile) for all the badly written sites that don't warn when required resources are not available. (For a very brief while it was common for sites that needed JS or cookies to warn when they were absent. Now the vast majority of web developers assume they are always available and sites just mysteriously break without notice if they aren't.) My normal routine when things break is to first enable enable JS, then enable cookies, and if the site still is broken, then switch browsers. Bill Bogstad wrote: Allowing other user ids to write on your screen/capture key mouse events seem to me to be a potential issue. Valid point, but you'll still have greatly reduced your attack surface. An exploit that leverages that probably couldn't be implemented purely with JS in the browser. It likely would require tricking you into installing (or doing so via a browser flaw) a plug-in with native code that uses X library calls. Unless such an exploit is useful in the single-user normal scenario, unlikely a malicious hacker will bother (assuming you aren't being specifically targeted and they know your setup). If this bugs you, try the Docker approach above, plus run a headless X server in the container and attach to it via VNC. I use multiple Firefox user profiles instead. ... This probably doesn't help memory usage I gather from the memory comment that you are running two separate instances of FF simultaneously. Generally I find that the controls provided by add-ons allow me to selective enable those when needed with just a click, but as noted, there are some cases where sites just seem to refuse to work, and for those I retreat to a different browser. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
Richard Pieri wrote: Tom Metro wrote: It's no worse than the previously mentioned solution that required sudo to switch to a dedicated browser user. If you are running a shared Docker is sudo root. Dedicated Firefox user is sudo !root. That's a huge difference. The Docker daemon runs as root. If the non-privileged user starting FF is put in the docker group and allowed to start any container, then yes, they have root. If instead a SetUID script or sudo rule is used to launch a specific container, which does not launch a root shell, then the resulting container and FF process won't have root privileges. In both cases you are using a root-level tool (sudo or Docker) to perform a privilege escalation in a controlled fashion to allow user X to execute a process as user Y. Anyway, in a single user system, you presumably already have sudo on your own machine, so this is a pointless distinction. (If you don't make use of the docker group and use sudo to run your docker commands, its no more of a security threat than anything else you run with sudo.) The more interesting question is which option better contains the Firefox process. Docker does not work perfectly well in the first place in my experience. That may very well be your experience. But some of us use it daily and find that it does the intended job. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
Richard Pieri wrote: Which in fact /reduces/ overall system security. Starting a Docker container requires root. It's no worse than the previously mentioned solution that required sudo to switch to a dedicated browser user. If you are running a shared system (neither of these solutions are likely the right fit), and you don't want the regular user to be in the privileged 'docker' group, then use a SetUID script (or sudo rule) that is restricted to launching the specific container. That's not even beginning to touch on the problems with updating the browsers. Because one doesn't update applications in a Docker container; one updates the whole container. That's the recommended philosophy for using Docker in production environments, but Docker also works perfectly well in a copy-on-change model, just like a VM. Update the browser in-situ. (You can save the state of the container if you want to be able to instantiate (or share) clones of the updated container image.) -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] sandboxing web browsers
On 6/21/2015 3:23 PM, Tom Metro wrote: It's no worse than the previously mentioned solution that required sudo to switch to a dedicated browser user. If you are running a shared Docker is sudo root. Dedicated Firefox user is sudo !root. That's a huge difference. That's the recommended philosophy for using Docker in production environments, but Docker also works perfectly well in a copy-on-change model, just like a VM. Update the browser in-situ. (You can save the state of the container if you want to be able to instantiate (or share) clones of the updated container image.) Docker does not work perfectly well in the first place in my experience. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
