users, "private" groups, and The Unix Way (was, Re: Is it me or is it sudo?)

[Bryn M. Reeves]

-----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 at redhat.com>
> 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-----