-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/03/2012 01:15 PM, Joel Rees wrote: > On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves <bmr@xxxxxxxxxx> > wrote: >> You're allowing the local sandbox user to connect to the local X >> server so any process running in one of your sandboxes can start >> a connection to X and start looking for vulnerabilities to >> exploit. > > Of which X11 still has its share, we are told. > > Humor me. Does running firefox this way, as a different user on > the same machine, increase risks, as compared to running firefox as > the user you are logged in as? If so, how? If the reason you are running the separate browser is to visit sites that you do not trust sufficiently to visit from your main user session then yes because the browser (and in turn X) is now exposed to those sites. If your choice is "or do nothing and run them in the normal session" then of course there is no difference. >> Due to the elevated privilege with which X runs this could >> include privilege escalations. > > Okay, so why doesn't Fedora drop privileges on Xorg like a certain > BSD does? I'm no X expert but historically the X server needed root privileges to use vm86 mode to interact with the video BIOS and to access the IO ports for the card so KMS for all drivers at least is required to be able to support this. OpenBSD modifies the Xorg source to allow privilege separation and this work has not made its way upstream (which is a problem for Fedora to include it). There are also legitimate questions about how useful all of this is; although OpenBSD provides their aperture driver to minimize the address space the X server can access Theo de Raadt has said this is just "the best we can do". OpenBSD also provides a vesafb driver that permits an unprivileged X server with no aperture driver but acceleration is not supported and performance suffers as a consequence. > Well, sure. That's going to happen when you run a server as root. > > But does it open holes to run the application accessing X as a > different user? ergo, holes that wouldn't be open when running the > same application as the user you logged in as? Yes; if you don't trust those applications or the data (sites) they operate on then you have a possible avenue for attacks. This is the point of sandbox -X. > This blog could help me figure out SELinux's ACL tools, which, if > I continue to use Fedora, it looks like I'll have to learn to use. > > In self-defense, if for no other reason. SELinux doesn't provide ACLs (Linux ACLs are primarily a file system feature that's independent of other security frameworks in use). > I notice that he is using mount-over tricks to augment the > protections. Fancy or funky? I'll have to re-read that when I have > time. Just sane. Linux has supported per-process mount namespaces for a very long time. They provide far stronger isolation than other methods. They're also worth getting to know as they are useful for many other tasks too. > You know, one of the problems with ACLs (and capabilities) is > getting them set up right. And you know how it ends up? > > Well, as you say, and as Walsh acknowledges, Use it/don't use it - it's up to you. I've used SELinux sandboxes and I find them very easy to use and considerably less maintenance effort than roll-your-own. YMMV of course but I prefer not to invent my own solutions to security problems when there are off the shelf answers that were developed by people who work on this stuff every day. There's also a tonne of good documentation for SELinux these days from basic administration to troubleshooting and advanced policy development: http://fedoraproject.org/wiki/SELinux > I've been trying to avoid what I'm sure amounts to blasphemy in > the eyes of some on these lists, but I am not particularly fond of > SELinux. Way too many convolutions to hide bugs in. If X11 must be > assumed to have bugs, so much more, the more recent and It's been around for well over a decade now and is pretty mature. Bugs still happen but I think they're no more troublesome than bugs in any other complex subsystem these days. The SELinux folks I know are also very responsive and helpful when dealing with user problems. > more complicated SELinux, especially in the patterns by which the > tools to set policy are run. Not sure which X sources you've looked at but this certainly isn't my impression of the two projects. The xorg-x11 sources weigh in at over 500,000 loc just for the server. Adding libX11 and a few other libraries quickly takes you over 750k. Adding up security/selinux from the kernel sources along with policycoreutils and libselinux you come to about 68,000 (and that's including all the pcu python stuff - without that you can take another 20,000 off). Even if you include the reference policy specs it's less than a quarter million lines. Regards, Bryn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk96+h0ACgkQ6YSQoMYUY97E7ACgjKKxX1dhyt//oaLsAbODMnth Y14AoITfx2JMUxa6SLn7nCwRW1gY6f/z =1+5b -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
