7 ms·

Off-topic, but I'm just going to start bringing this up in every thread like this ... We need a recipe / toolchain for running a browser instance in a chroot j

by rsync 10y ago

Off-topic, but I'm just going to start bringing this up in every thread like this ... We need a recipe / toolchain for running a browser instance in a chroot jail. With a head. GUI. On the desktop. I want to fire up a "banking browser" (or "danger browser" or "social media browser") that runs on its own IP, in its own chroot, and I can revert to virgin snapshot state anytime I want ... and I don't want to fire up a full-blown VM for eac of these ... What is standing in the way of making this happen ? Who is working on things related to this that I can donate funds to or establish a bounty ?

noja 10y ago
Sounds like Qubes OS https://www.qubes-os.org/ https://www.qubes-os.org/
- rsync 10y ago
  The idea here is that I set up a chroot jail for firefox or chrome and configure it with things like local filesystem for cookies and cache and certs, etc. It would also get its own unique IP, this jail. Then I fire up firefox inside that chroot jail and use it to visit some websites ... and then I can wipe the whole thing out and redeploy again later, starting from scratch. I don't need to trust incognito mode, I don't need to trust wiping cache or tabs talking to each other (or not) and I can worry a lot less about browser level exploits. I can even put in firewall rules so that my "banking" instance can only talk to boa.com and scotttrade.com (or whatever). It's totally workable (and I have done it) with vmware. Make a "bank browsing" VM and revert to pristine snapshot every day. The problem is that this is terribly heavyweight and overkill when I don't need a full blown VM. It's not even really a browser issue - the real issue is, how do you jail a GUI application in X such that that window is in a chroot jail, distinct from the rest of your desktop?
  - napsterbr 10y ago
    Did this a few months ago, somewhat straightforward. A "generic" recipe for any UNIX-based OS would be: 1 - Create a container (Docker, Jails, maybe even chroot) 2 - Assign an ip to the container, NAT to it 3 - Install firefox on that container 4 - Run a SSHD server, enable X11 forwarding 5 - Mount the relevant container's folders to your root fs (eg: map $CONTAINER/.mozzila and $CONTAINER/Downloads to $HOME/jailed-browser/) 6 - Add an ssh config for quick alias 7 - Run `ssh container firefox` and profit Here's a nice example using FreeBSD jails (I remember following this tutorial, everything worked out fine): https://forums.freebsd.org/threads/53362/ https://forums.freebsd.org/threads/53362/ My experience with it, though, wasn't great. X11 forwarding through SSH was quite laggy (even after performing some optimizations on the connection). Good luck if you want to set-up audio/mic support. It's a nice solution for a one-time banking login, not for day-to-day use.
    - rsync 10y ago
      "Did this a few months ago, somewhat straightforward. A "generic" recipe for any UNIX-based OS would be:" Thank you very much! I will give this a try immediately.
  - developer2 10y ago
    >> this is terribly heavyweight and overkill when I don't need a full blown VM The entire concept you're aiming to set up is terribly heavyweight and overkill. If you're knowledgeable enough to be discussing VMs and chroots, you must realize that what you are proposing is being careful to the point of paranoia à la tinfoil hat. Those of us who know how to stay as safe as possible via "basic" methods of security should be sleeping soundly knowing we're already in the top 5-10% of consumers. Install OS security updates, use a virus scanner and firewall, don't install pirated software (more likely to contain malware), and you're better off than most people by a significant margin. You're talking about barely making a dent in the chances of your credentials or sessions being compromised. Private browsing, a separate browser instance, a VM, or chroot makes no difference if you have malware with a keylogger on the host system. Give yourself a break, realize that there is no such thing as "perfect security", and stop worrying so much. The amount of energy you're pouring into "banking safely" is not a sane endeavor. It serves no useful purpose. You could be investing this time and energy into something far more likely to improve your quality of life (eg: family, friends, health, etc.).
    - andai 10y ago
      tl;dr relax, go for a walk
    - jjeaff 10y ago
      I've seen so many people stress about getting their credit card stolen or bank accounts hacked. It's rather ridiculous considering you don't bear the liability of a hack. If you didn't access or approve a usage of your accounts, the banks just give it back. I have had money stolen more than once from skimmers and I have never had any trouble getting it all back.
j_s 10y ago
Windows: https://www.sandboxie.com/ https://www.sandboxie.com/ $35 home | $50/yr commercial Find Linux options here: http://alternativeto.net/software/sandboxie/?platform=linux http://alternativeto.net/software/sandboxie/?platform=linux - maybe someone can pick up https://github.com/tsgates/mbox https://github.com/tsgates/mbox At least 1 VM is strongly recommended but you could containerize within that. Edit: toolchain for running a browser instance in a chroot jail. With a head. GUI. On the desktop - it's here today (with commercial support), just run Windows+Sandboxie in a VM. Yowch!
uggedal 10y ago
https://firejail.wordpress.com/ https://firejail.wordpress.com/
biot 10y ago
I always thought http://www.zerovm.org/ http://www.zerovm.org/ had a lot of potential. I recall an HN story where someone used this to spin up a ZeroVM instance for each request that came in over an API and tear it down once the request was finished. That sort of speed and isolation would work really well for this use case.
kalcode 10y ago
I don't know much about this but I swore I read the chrome uses chroot for its sandboxing. Would that not already accomplish what you wanted? https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/master/docs...
aseipp 10y ago
It might sound unpopular but, I've always thought these things are a bit of shenanigans, honestly. It sounds like it increases security a lot but it seems to just be a little extra paper on top. It's good for resource control (stop Chrome from eating all RAM) or installing a browser quickly in a container/docker/jail/whatever, but security wise I think it's not the right solution. The thing is, a chroot jail doesn't really protect my browser in the way I want to (if I'm speaking personally, I guess). It's not the right level of granularity. If an exploit compromises my browser, it would, essentially, have vast amounts of access to my personal information already, simply due to the nature of a browser being stateful and trusted by the user. Getting root or whatever beyond that is nice I guess, but that's game over for most people. This is true for the vast majority of most computer users. I don't clear my browser history literally every day and 'wipe the slate clean', I like having search history and trained autocomplete, and it's kind of weird to expect people suddenly not to. It seems like it's a move laterally, in a direction that only really satiates some very technically aware users. Even then, I'd say this approach is still fundamentally dangerous for competent users -- a simple mistake or a flaw in the application you can't anticipate, or your own mistake, could expose you easily. A more instructive example is an email client. If I use thunderbird and put it in a chroot jail, sync part of my mail spool, and then someone sends me an HTML email that exploits a Gecko rendering flaw and owns me 'in the jail' -- then they now have access to my spool! And my credentials. They can just disguise access to the container and do a password reset, for example, and I'm screwed. Depending on the interaction method of the application, things like Stagefright were auto-triggered, for example, just solely by sending SMS. It's a very dangerous game to play at that point, when applications are trying to be so in-our-face today (still waiting for a browser exploit that can be triggered even out-of-focus, through desktop notifications...) The attack surface for a browser, and most stateful, trusted apps -- basically starts and ends at there, really. For all intents and purposes, an individual's browser or email client is just as relatively valuable as any company's SQL database. Think: if you put a PostgreSQL instance inside a jail, and someone exploits your SQL database... is your data safe? Or do they just exfiltrate your DB dump and walk away? Does a company wipe their database every week to keep hackers from taking it? Meaningful mitigation has to come, I think, in the way Chrome does it: by doing extensive application level sandboxing. Making it part of the design, in a real, coherent way. That requires a lot of work. It's why Firefox has taken years to do it -- and is pissing so many people off to get there by breaking the extension model, so they can meaningfully sandbox. Aside from just attack surface concerns though, jails and things like containers still have some real technical limitations that stand in the way of users. Even things like drag-and-drop from desktop into container is a bit convoluted (maybe Wayland makes this easier? I don't know how Qubes does it), and I use 1Password, so the kind of interaction between my key database means we're back at square 1: where browser compromise 'in the sandbox' still means you get owned in all the ways that matter. Other meaningful mitigations exist beyond 'total redesign' but they're more technical in nature... Things like more robust anti-exploit mechanisms, for example, in our toolchains and processes. That's also very hard work, but I think it's also a lot more fruitful than "containerize/jail it all, and hope for the best".
j_s 10y ago
Paging HN user christux of http://tux.io http://tux.io Ask HN | https://news.ycombinator.com/item?id=14245428 https://news.ycombinator.com/item?id=14245428 > public access to non-root desktops in LXC containers Show HN | https://news.ycombinator.com/item?id=14245447 https://news.ycombinator.com/item?id=14245447 > a Linux desktop in your browser
megous 10y ago
Or you can have a banking computer, danger computer and social media computer with everything truly separate. These days, it's quite cheap, as you can get an ARM board with HDMI output for $18 incl shipping and no management engine blobs. You can create arbitrary local networks with it, and isolate concerns in separate hardware. If the "social desktop" get's compromised or even rooted, the attacker would still need to find a way through the physical router/firewall, etc. It would not be just a question of finding/using VM/container/chroot escape vulnerabilities. You can also air gap certain endpoints. Physical security? Use FDE and pop the sd card out of the SBC and take it with you when you're out of home. Security against rubber hose cryptoanalysis or 'contempt of the court' cryptoanalysis? Devise some way to quickly destroy the sd card when necessary. Then there's nothing to rubber hose you for. /s? Maybe. But it's all possible today, rather easy to do, and cheap. :)
yebyen 10y ago
Maybe you already saw this: https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ https://blog.jessfraz.com/post/docker-containers-on-the-desk... It's pretty dated, but the state of containers has only improved since 2015, and this was usable for Google Hangouts (video) and YouTube all the way back then. https://hub.docker.com/r/jess/chrome/ https://hub.docker.com/r/jess/chrome/ ^ This got a push less than 24 hours ago https://github.com/jessfraz/dockerfiles/blob/master/chrome/stable/Dockerfile https://github.com/jessfraz/dockerfiles/blob/master/chrome/s... ^ This is the Dockerfile, in a repo full of Dockerfiles for other things you might have had trouble putting into a container. I tried this myself and had problems because (I think) I was on a very old LTS/stable distro with a necessity to use pretty old Docker release. This person is a maintainer on the Docker core team, so is most definitely tracking newest releases. I use Chrome in a headless setup with Kubernetes and Docker (Jenkins with kubernetes-plugin) but it's not Headless Chrome, it's Xvfb that makes my setup headless. Chrome itself works great in a container. It's one excellent way to keep it from eating up gobs of RAM like it does: just give it less RAM (cgroups). If you said "chroot jail" on purpose because you don't want Docker, I don't know why exactly, maybe because you don't think you can run graphical apps in a Docker container, but it's not true. You can! You could also cobble something together and do it without Docker, but I'm not recommending that, I just saw this and thought it would be exactly what you're looking for. Hope this helps!

by rsync 10y ago

noja 10y ago

Sounds like Qubes OS https://www.qubes-os.org/ https://www.qubes-os.org/

rsync 10y ago
The idea here is that I set up a chroot jail for firefox or chrome and configure it with things like local filesystem for cookies and cache and certs, etc. It would also get its own unique IP, this jail. Then I fire up firefox inside that chroot jail and use it to visit some websites ... and then I can wipe the whole thing out and redeploy again later, starting from scratch. I don't need to trust incognito mode, I don't need to trust wiping cache or tabs talking to each other (or not) and I can worry a lot less about browser level exploits. I can even put in firewall rules so that my "banking" instance can only talk to boa.com and scotttrade.com (or whatever). It's totally workable (and I have done it) with vmware. Make a "bank browsing" VM and revert to pristine snapshot every day. The problem is that this is terribly heavyweight and overkill when I don't need a full blown VM. It's not even really a browser issue - the real issue is, how do you jail a GUI application in X such that that window is in a chroot jail, distinct from the rest of your desktop?
- napsterbr 10y ago
  Did this a few months ago, somewhat straightforward. A "generic" recipe for any UNIX-based OS would be: 1 - Create a container (Docker, Jails, maybe even chroot) 2 - Assign an ip to the container, NAT to it 3 - Install firefox on that container 4 - Run a SSHD server, enable X11 forwarding 5 - Mount the relevant container's folders to your root fs (eg: map $CONTAINER/.mozzila and $CONTAINER/Downloads to $HOME/jailed-browser/) 6 - Add an ssh config for quick alias 7 - Run `ssh container firefox` and profit Here's a nice example using FreeBSD jails (I remember following this tutorial, everything worked out fine): https://forums.freebsd.org/threads/53362/ https://forums.freebsd.org/threads/53362/ My experience with it, though, wasn't great. X11 forwarding through SSH was quite laggy (even after performing some optimizations on the connection). Good luck if you want to set-up audio/mic support. It's a nice solution for a one-time banking login, not for day-to-day use.
  - rsync 10y ago
    "Did this a few months ago, somewhat straightforward. A "generic" recipe for any UNIX-based OS would be:" Thank you very much! I will give this a try immediately.
- developer2 10y ago
  >> this is terribly heavyweight and overkill when I don't need a full blown VM The entire concept you're aiming to set up is terribly heavyweight and overkill. If you're knowledgeable enough to be discussing VMs and chroots, you must realize that what you are proposing is being careful to the point of paranoia à la tinfoil hat. Those of us who know how to stay as safe as possible via "basic" methods of security should be sleeping soundly knowing we're already in the top 5-10% of consumers. Install OS security updates, use a virus scanner and firewall, don't install pirated software (more likely to contain malware), and you're better off than most people by a significant margin. You're talking about barely making a dent in the chances of your credentials or sessions being compromised. Private browsing, a separate browser instance, a VM, or chroot makes no difference if you have malware with a keylogger on the host system. Give yourself a break, realize that there is no such thing as "perfect security", and stop worrying so much. The amount of energy you're pouring into "banking safely" is not a sane endeavor. It serves no useful purpose. You could be investing this time and energy into something far more likely to improve your quality of life (eg: family, friends, health, etc.).
  - andai 10y ago
    tl;dr relax, go for a walk
  - jjeaff 10y ago
    I've seen so many people stress about getting their credit card stolen or bank accounts hacked. It's rather ridiculous considering you don't bear the liability of a hack. If you didn't access or approve a usage of your accounts, the banks just give it back. I have had money stolen more than once from skimmers and I have never had any trouble getting it all back.

j_s 10y ago

Windows: https://www.sandboxie.com/ https://www.sandboxie.com/ $35 home | $50/yr commercial Find Linux options here: http://alternativeto.net/software/sandboxie/?platform=linux http://alternativeto.net/software/sandboxie/?platform=linux - maybe someone can pick up https://github.com/tsgates/mbox https://github.com/tsgates/mbox At least 1 VM is strongly recommended but you could containerize within that. Edit: toolchain for running a browser instance in a chroot jail. With a head. GUI. On the desktop - it's here today (with commercial support), just run Windows+Sandboxie in a VM. Yowch!

uggedal 10y ago

https://firejail.wordpress.com/ https://firejail.wordpress.com/

biot 10y ago

I always thought http://www.zerovm.org/ http://www.zerovm.org/ had a lot of potential. I recall an HN story where someone used this to spin up a ZeroVM instance for each request that came in over an API and tear it down once the request was finished. That sort of speed and isolation would work really well for this use case.

kalcode 10y ago

I don't know much about this but I swore I read the chrome uses chroot for its sandboxing. Would that not already accomplish what you wanted? https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/master/docs...

aseipp 10y ago

It might sound unpopular but, I've always thought these things are a bit of shenanigans, honestly. It sounds like it increases security a lot but it seems to just be a little extra paper on top. It's good for resource control (stop Chrome from eating all RAM) or installing a browser quickly in a container/docker/jail/whatever, but security wise I think it's not the right solution. The thing is, a chroot jail doesn't really protect my browser in the way I want to (if I'm speaking personally, I guess). It's not the right level of granularity. If an exploit compromises my browser, it would, essentially, have vast amounts of access to my personal information already, simply due to the nature of a browser being stateful and trusted by the user. Getting root or whatever beyond that is nice I guess, but that's game over for most people. This is true for the vast majority of most computer users. I don't clear my browser history literally every day and 'wipe the slate clean', I like having search history and trained autocomplete, and it's kind of weird to expect people suddenly not to. It seems like it's a move laterally, in a direction that only really satiates some very technically aware users. Even then, I'd say this approach is still fundamentally dangerous for competent users -- a simple mistake or a flaw in the application you can't anticipate, or your own mistake, could expose you easily. A more instructive example is an email client. If I use thunderbird and put it in a chroot jail, sync part of my mail spool, and then someone sends me an HTML email that exploits a Gecko rendering flaw and owns me 'in the jail' -- then they now have access to my spool! And my credentials. They can just disguise access to the container and do a password reset, for example, and I'm screwed. Depending on the interaction method of the application, things like Stagefright were auto-triggered, for example, just solely by sending SMS. It's a very dangerous game to play at that point, when applications are trying to be so in-our-face today (still waiting for a browser exploit that can be triggered even out-of-focus, through desktop notifications...) The attack surface for a browser, and most stateful, trusted apps -- basically starts and ends at there, really. For all intents and purposes, an individual's browser or email client is just as relatively valuable as any company's SQL database. Think: if you put a PostgreSQL instance inside a jail, and someone exploits your SQL database... is your data safe? Or do they just exfiltrate your DB dump and walk away? Does a company wipe their database every week to keep hackers from taking it? Meaningful mitigation has to come, I think, in the way Chrome does it: by doing extensive application level sandboxing. Making it part of the design, in a real, coherent way. That requires a lot of work. It's why Firefox has taken years to do it -- and is pissing so many people off to get there by breaking the extension model, so they can meaningfully sandbox. Aside from just attack surface concerns though, jails and things like containers still have some real technical limitations that stand in the way of users. Even things like drag-and-drop from desktop into container is a bit convoluted (maybe Wayland makes this easier? I don't know how Qubes does it), and I use 1Password, so the kind of interaction between my key database means we're back at square 1: where browser compromise 'in the sandbox' still means you get owned in all the ways that matter. Other meaningful mitigations exist beyond 'total redesign' but they're more technical in nature... Things like more robust anti-exploit mechanisms, for example, in our toolchains and processes. That's also very hard work, but I think it's also a lot more fruitful than "containerize/jail it all, and hope for the best".

j_s 10y ago

Paging HN user christux of http://tux.io http://tux.io Ask HN | https://news.ycombinator.com/item?id=14245428 https://news.ycombinator.com/item?id=14245428 > public access to non-root desktops in LXC containers Show HN | https://news.ycombinator.com/item?id=14245447 https://news.ycombinator.com/item?id=14245447 > a Linux desktop in your browser

megous 10y ago

Or you can have a banking computer, danger computer and social media computer with everything truly separate. These days, it's quite cheap, as you can get an ARM board with HDMI output for $18 incl shipping and no management engine blobs. You can create arbitrary local networks with it, and isolate concerns in separate hardware. If the "social desktop" get's compromised or even rooted, the attacker would still need to find a way through the physical router/firewall, etc. It would not be just a question of finding/using VM/container/chroot escape vulnerabilities. You can also air gap certain endpoints. Physical security? Use FDE and pop the sd card out of the SBC and take it with you when you're out of home. Security against rubber hose cryptoanalysis or 'contempt of the court' cryptoanalysis? Devise some way to quickly destroy the sd card when necessary. Then there's nothing to rubber hose you for. /s? Maybe. But it's all possible today, rather easy to do, and cheap. :)

yebyen 10y ago

Maybe you already saw this: https://blog.jessfraz.com/post/docker-containers-on-the-desktop/ https://blog.jessfraz.com/post/docker-containers-on-the-desk... It's pretty dated, but the state of containers has only improved since 2015, and this was usable for Google Hangouts (video) and YouTube all the way back then. https://hub.docker.com/r/jess/chrome/ https://hub.docker.com/r/jess/chrome/ ^ This got a push less than 24 hours ago https://github.com/jessfraz/dockerfiles/blob/master/chrome/stable/Dockerfile https://github.com/jessfraz/dockerfiles/blob/master/chrome/s... ^ This is the Dockerfile, in a repo full of Dockerfiles for other things you might have had trouble putting into a container. I tried this myself and had problems because (I think) I was on a very old LTS/stable distro with a necessity to use pretty old Docker release. This person is a maintainer on the Docker core team, so is most definitely tracking newest releases. I use Chrome in a headless setup with Kubernetes and Docker (Jenkins with kubernetes-plugin) but it's not Headless Chrome, it's Xvfb that makes my setup headless. Chrome itself works great in a container. It's one excellent way to keep it from eating up gobs of RAM like it does: just give it less RAM (cgroups). If you said "chroot jail" on purpose because you don't want Docker, I don't know why exactly, maybe because you don't think you can run graphical apps in a Docker container, but it's not true. You can! You could also cobble something together and do it without Docker, but I'm not recommending that, I just saw this and thought it would be exactly what you're looking for. Hope this helps!