How to Run a More Secure Browser | Hacker News Reader

How to Run a More Secure Browser

dragonflybsd.org

90 pointstdurden35 comments

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...

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.

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.

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.).

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_sec...

> 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.

> 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.

>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.

Firejail (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.)

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.

Indeed, I remember this was created to thwart an older (Java?) exploit that specifically grabbed keys in ~/.ssh

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?

I think we've seen it once so far, for a Flash exploit that didn't have a sandbox escape in Chrome.

PPAPI plugins are sandboxed. That's their major difference from NPAPI plugins. The API itself is otherwise extremely similar.

I think you may be confused about who you're replying to and what subject you're replying on.

Upon re-reading the thread, I think you're right. Sorry!

No worries. :)

And, upon looking at your profile, I'm putting my foot in my mouth. Like, the whole thing, heel and all. :)

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.

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

You just expose the /dev/video device to the jail. Completely reasonable.

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.

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

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

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

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.

How does this compare with the Qubes OS approach?

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.

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.

If the "something malicious" is run by a user that only has permissions to read/write to his home, it's perfectly contained.

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.

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..

This is really interesting. If you look at what Microsoft is doing with Windows 10 with virtualization based security you can see that the Qubes approach is going to go mainstream within the next year. in addition to moving secrets that are normally stored in the kernel into a separate statically linked trusted OS running in it's own VM (that's currently available in credential guard) they will be running edge in a separate VM as well.

Qubes is ahead of its time and far more versatile than most other solutions at this time.

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?

The recent attacks where your dotfiles and dotdirs are stolen so they get your ssh keys and more

> 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.

    [...]

Reply on news.ycombinator.com