
How to Run a More Secure Browser - tdurden
https://www.dragonflybsd.org/docs/docs/handbook/RunSecureBrowser/
======
comex
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...](http://theinvisiblethings.blogspot.de/2011/04/linux-security-
circus-on-gui-isolation.html)

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.

~~~
Fnoord
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...](https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_security_domains.png)

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

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

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

~~~
dguido
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
I think we've seen it once so far, for a Flash exploit that didn't have a
sandbox escape in Chrome.

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

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

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

~~~
justinschuh
No worries. :)

------
joatmon-snoo
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
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
You just expose the /dev/video device to the jail. Completely reasonable.

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

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

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

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

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

------
ilurkedhere
How does this compare with the Qubes OS approach?

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

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

------
dguido
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?

~~~
contras1970
> _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.
    
        [...]

