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):
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.
>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.
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.).
> 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.
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.
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?
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
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.
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.
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.
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.
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?
> 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.
[...]
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.