6 ms·

How to Run a More Secure Browser

90 points by tdurden 10y ago

comex 10y ago
Hmm... I don't think this is actually a secure approach, as by default X is not secure. Any client with access can do things like sniff and inject keystrokes (even forwarded over SSH, depending on the value of ForwardX11Trusted in ssh_config): http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.de/2011/04/linux-security... I could be wrong. Apparently X11 has the SECURITY and XACE extensions which are theoretically capable of preventing this, but nobody uses them (except SSH, see above). It's possible that DragonFlyBSD has these integrated somehow and makes the directions secure, but I don't think so.
- Zizzle 10y ago
  Even if these extensions are being used I'm sure the attack surface of X11, it's extensions and it's drivers is large enough to make it trivial to breach. Even compared to a modern browser like Chrome.
  - groovy2shoes 10y ago
    Do you mean Xorg rather than X11? X11 is just a protocol (or a set of protocols, depending on how you look at it). Xorg, on the other hand, is the most popular implementation. There are (were?) others, some of them much smaller in terms of source code (but also features, platform support, etc.).
- Fnoord 10y ago
  This is written in a DragonFlyBSD context, and I don't think there's Wayland for *BSD (I could be wrong). Also, how does this setup compare with Subgraph OS which uses Xpra? There are better alternatives: Containers. Run your browser in a container. There are some excellent videos explaining how this works on YouTube. VMs. Like Qubes OS. You run your browser in a separate VM as your other applications. This picture explains it rather well: https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_security_domains.png https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_sec...
  - JoshTriplett 10y ago
    > I don't think there's Wayland for *BSD Wayland works on FreeBSD, and I've seen some reports of it working on DragonFlyBSD as well.
  - deleted 10y ago
    [deleted]
- gbrown_ 10y ago
  > Hmm... I don't think this is actually a secure approach, as by default X is not secure. I think the post is more about containing what the browser has access to in terms of Unix permissions in the event of it being controlled maliciously. The attack vector of X11 is equally applicable with or without the steps in this post.
- upofadown 10y ago
  >Apparently X11 has the SECURITY and XACE extensions which are theoretically capable of preventing this, but nobody uses them ... My experience is that the SECURITY extension is universal these days using MIT-MAGIC-COOKIE-1. To do otherwise would be insane as any user on the system would be able to sniff your keystrokes and mess with your windows. That would include utility users and probably even chrooted stuff. However in this case the SECURITY extension is specifically overridden by copying the ~/.Xauthority file to the browser user. So your comment is still valid. The article discusses the performance implications of not doing the override.
hlieberman 10y ago
Firejail (https://firejail.wordpress.com/ https://firejail.wordpress.com/) seems a good first step before jumping through those hoops. (Though, to be fair to the post, you can't use firejail on a *BSD, since it needs seccomp-bpf and other Linux specific things.)
joatmon-snoo 10y ago
Aren't jails one of the things that BSD is known for? (Now that Docker is a thing.) And the primary goal of jails in the first place was security, so what does this offer over running your browser in a jail? There are a ton of rebuttals I can imagine but I don't know nearly enough about any of the stuff involved here to determine whether any of them are true.
- drvdevd 10y ago
  Yes this is just basic UNIX isolation 101. It's a good article for that purpose. And I would use a jail as well if I were solving this problem because why not. [Edit] not sure about video acceleration in the jail though
  - feld 10y ago
    You just expose the /dev/video device to the jail. Completely reasonable.
tptacek 10y ago
This is a pretty good illustration of the challenge of sandboxing: stipulate for a second that you could contain a browser exploit to a specific Unix UID (that's a very ambitious claim!) --- you're still left with a pretty big problem in this security model: the attacker might still be left with control of all your browser sessions. For a big chunk of users --- perhaps the majority of all users --- this is all attackers actually want.
- joshbaptiste 10y ago
  Indeed, I remember this was created to thwart an older (Java?) exploit that specifically grabbed keys in ~/.ssh
- dguido 10y ago
  I have been waiting for years for attacks that operate entirely within the sandbox and steal cookies from memory, for example. What is more valuable that your Google cookies in a modern browser session? Who cares about machine access?
  - justinschuh 10y ago
    I think we've seen it once so far, for a Flash exploit that didn't have a sandbox escape in Chrome.
    - groovy2shoes 10y ago
      PPAPI plugins are sandboxed. That's their major difference from NPAPI plugins. The API itself is otherwise extremely similar.
      - justinschuh 10y ago
        I think you may be confused about who you're replying to and what subject you're replying on.
        10y ago
ilurkedhere 10y ago
How does this compare with the Qubes OS approach?
- rahrahrah 10y ago
  I probably don't know enough to be talking about these things, but it seems to me that the Qubes OS approach is more complex and less battle tested. User permissions in Linux have been around forever.
  - angry_octet 10y ago
    Unix permissons by themselves are notoriously not capable of containing and restricting something malicious. The kernel exposes a huge attack surface. That is why it is beter to use VMs, which expose the much smaller hypervisor and provide only simple interface protocols.
    - rahrahrah 10y ago
      If the "something malicious" is run by a user that only has permissions to read/write to his home, it's perfectly contained.
      - angry_octet 10y ago
        Unfortunately not true. By default programs will also have permission to do things like mmap, open network sockets, use IPC, learn about other processes and the kernel via proc (helping to defeat randomised protection against stack overflow) and many other areas. Google for kernel hardening and PaX.
- drvdevd 10y ago
  Qubes uses Xen for isolation as I understand it -- essentially putting different programs in their own specialized, locked down domU. So it's probably much more robust against attack than this approach. [edit] but I'm not arguing its a better solution for you. Depends on your needs and hardware, etc..
deleted 10y ago
[deleted]
drc0 10y ago
why is the suggested example ssh + command instead of sudo -u user command ?
- Ziomislaw 10y ago
  probably to make switching from local account to a jail/other machine, easier in the future.
SixSigma 10y ago
Or, have a user who runs as a Vnc server then you get a whole user desktop account different to yours and no X11 exploits.
dguido 10y ago
lol this is totally wrong. One browser exploit coupled with one kernel exploit, as per standard, still takes over the whole machine. Does this make the kernel step any harder? What attacks are they even mitigating?
- feld 10y ago
  The recent attacks where your dotfiles and dotdirs are stolen so they get your ssh keys and more
- contras1970 10y ago
  > lol this is totally wrong. One browser exploit coupled with one kernel exploit [...] You seem to contradict yourself there. > What attacks are they even mitigating? The page is based on this email to users@dragonflybsd.org Date: Tue, 11 Aug 2015 10:32:58 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: users@dragonflybsd.org Subject: Running firefox a bit more safely - HOWTO As people may know a firefox hack was found in the wild that allows any accessible file to be read. This hack was due to a bug in firefox's internal PDF viewer. The exploit that was found in the wild was trying to snarf developer-related files such as .ssh configuration files and keys. [...]
upofadown 10y ago
As others have already pointed out, this approach mostly protects the contents of your home directory from a cracked browser. It doesn't entirely isolate things at the X level. A more secure (and perhaps simpler approach) is to have each user run their own X server on a separate virtual console. The size of an X server isn't really significant these days. So each X server will be entirely isolated from the other using the regular X security stuff. You wouldn't need much of a desktop environment for the extra sessions. You might not even need a window manager, depending. You could have one extra session for your banking stuff and/or another for your sketchy streaming sites.
fowl2 10y ago
Wouldn't dropping privileges like this prevent Chrome's own sandbox from working correctly?

90 points by tdurden 10y ago

comex 10y ago

Hmm... I don't think this is actually a secure approach, as by default X is not secure. Any client with access can do things like sniff and inject keystrokes (even forwarded over SSH, depending on the value of ForwardX11Trusted in ssh_config): http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.de/2011/04/linux-security... I could be wrong. Apparently X11 has the SECURITY and XACE extensions which are theoretically capable of preventing this, but nobody uses them (except SSH, see above). It's possible that DragonFlyBSD has these integrated somehow and makes the directions secure, but I don't think so.

Zizzle 10y ago
Even if these extensions are being used I'm sure the attack surface of X11, it's extensions and it's drivers is large enough to make it trivial to breach. Even compared to a modern browser like Chrome.
- groovy2shoes 10y ago
  Do you mean Xorg rather than X11? X11 is just a protocol (or a set of protocols, depending on how you look at it). Xorg, on the other hand, is the most popular implementation. There are (were?) others, some of them much smaller in terms of source code (but also features, platform support, etc.).
Fnoord 10y ago
This is written in a DragonFlyBSD context, and I don't think there's Wayland for *BSD (I could be wrong). Also, how does this setup compare with Subgraph OS which uses Xpra? There are better alternatives: Containers. Run your browser in a container. There are some excellent videos explaining how this works on YouTube. VMs. Like Qubes OS. You run your browser in a separate VM as your other applications. This picture explains it rather well: https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_security_domains.png https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_sec...
- JoshTriplett 10y ago
  > I don't think there's Wayland for *BSD Wayland works on FreeBSD, and I've seen some reports of it working on DragonFlyBSD as well.
- deleted 10y ago
  [deleted]
gbrown_ 10y ago
> Hmm... I don't think this is actually a secure approach, as by default X is not secure. I think the post is more about containing what the browser has access to in terms of Unix permissions in the event of it being controlled maliciously. The attack vector of X11 is equally applicable with or without the steps in this post.
upofadown 10y ago
>Apparently X11 has the SECURITY and XACE extensions which are theoretically capable of preventing this, but nobody uses them ... My experience is that the SECURITY extension is universal these days using MIT-MAGIC-COOKIE-1. To do otherwise would be insane as any user on the system would be able to sniff your keystrokes and mess with your windows. That would include utility users and probably even chrooted stuff. However in this case the SECURITY extension is specifically overridden by copying the ~/.Xauthority file to the browser user. So your comment is still valid. The article discusses the performance implications of not doing the override.

hlieberman 10y ago

Firejail (https://firejail.wordpress.com/ https://firejail.wordpress.com/) seems a good first step before jumping through those hoops. (Though, to be fair to the post, you can't use firejail on a *BSD, since it needs seccomp-bpf and other Linux specific things.)

joatmon-snoo 10y ago

Aren't jails one of the things that BSD is known for? (Now that Docker is a thing.) And the primary goal of jails in the first place was security, so what does this offer over running your browser in a jail? There are a ton of rebuttals I can imagine but I don't know nearly enough about any of the stuff involved here to determine whether any of them are true.

drvdevd 10y ago
Yes this is just basic UNIX isolation 101. It's a good article for that purpose. And I would use a jail as well if I were solving this problem because why not. [Edit] not sure about video acceleration in the jail though
- feld 10y ago
  You just expose the /dev/video device to the jail. Completely reasonable.

tptacek 10y ago

This is a pretty good illustration of the challenge of sandboxing: stipulate for a second that you could contain a browser exploit to a specific Unix UID (that's a very ambitious claim!) --- you're still left with a pretty big problem in this security model: the attacker might still be left with control of all your browser sessions. For a big chunk of users --- perhaps the majority of all users --- this is all attackers actually want.

joshbaptiste 10y ago
Indeed, I remember this was created to thwart an older (Java?) exploit that specifically grabbed keys in ~/.ssh
dguido 10y ago
I have been waiting for years for attacks that operate entirely within the sandbox and steal cookies from memory, for example. What is more valuable that your Google cookies in a modern browser session? Who cares about machine access?
- justinschuh 10y ago
  I think we've seen it once so far, for a Flash exploit that didn't have a sandbox escape in Chrome.
  - groovy2shoes 10y ago
    PPAPI plugins are sandboxed. That's their major difference from NPAPI plugins. The API itself is otherwise extremely similar.
    - justinschuh 10y ago
      I think you may be confused about who you're replying to and what subject you're replying on.
      - 10y ago

ilurkedhere 10y ago

How does this compare with the Qubes OS approach?

rahrahrah 10y ago
I probably don't know enough to be talking about these things, but it seems to me that the Qubes OS approach is more complex and less battle tested. User permissions in Linux have been around forever.
- angry_octet 10y ago
  Unix permissons by themselves are notoriously not capable of containing and restricting something malicious. The kernel exposes a huge attack surface. That is why it is beter to use VMs, which expose the much smaller hypervisor and provide only simple interface protocols.
  - rahrahrah 10y ago
    If the "something malicious" is run by a user that only has permissions to read/write to his home, it's perfectly contained.
    - angry_octet 10y ago
      Unfortunately not true. By default programs will also have permission to do things like mmap, open network sockets, use IPC, learn about other processes and the kernel via proc (helping to defeat randomised protection against stack overflow) and many other areas. Google for kernel hardening and PaX.
drvdevd 10y ago
Qubes uses Xen for isolation as I understand it -- essentially putting different programs in their own specialized, locked down domU. So it's probably much more robust against attack than this approach. [edit] but I'm not arguing its a better solution for you. Depends on your needs and hardware, etc..

deleted 10y ago

[deleted]

drc0 10y ago

why is the suggested example ssh + command instead of sudo -u user command ?

Ziomislaw 10y ago
probably to make switching from local account to a jail/other machine, easier in the future.

SixSigma 10y ago

Or, have a user who runs as a Vnc server then you get a whole user desktop account different to yours and no X11 exploits.

dguido 10y ago

lol this is totally wrong. One browser exploit coupled with one kernel exploit, as per standard, still takes over the whole machine. Does this make the kernel step any harder? What attacks are they even mitigating?

feld 10y ago
The recent attacks where your dotfiles and dotdirs are stolen so they get your ssh keys and more
contras1970 10y ago
> lol this is totally wrong. One browser exploit coupled with one kernel exploit [...] You seem to contradict yourself there. > What attacks are they even mitigating? The page is based on this email to users@dragonflybsd.org Date: Tue, 11 Aug 2015 10:32:58 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: users@dragonflybsd.org Subject: Running firefox a bit more safely - HOWTO As people may know a firefox hack was found in the wild that allows any accessible file to be read. This hack was due to a bug in firefox's internal PDF viewer. The exploit that was found in the wild was trying to snarf developer-related files such as .ssh configuration files and keys. [...]

upofadown 10y ago

As others have already pointed out, this approach mostly protects the contents of your home directory from a cracked browser. It doesn't entirely isolate things at the X level. A more secure (and perhaps simpler approach) is to have each user run their own X server on a separate virtual console. The size of an X server isn't really significant these days. So each X server will be entirely isolated from the other using the regular X security stuff. You wouldn't need much of a desktop environment for the extra sessions. You might not even need a window manager, depending. You could have one extra session for your banking stuff and/or another for your sketchy streaming sites.

fowl2 10y ago

Wouldn't dropping privileges like this prevent Chrome's own sandbox from working correctly?