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

Joel Rees joel.rees at gmail.com
Tue Apr 3 12:19:18 UTC 2012


(woops, missed the user list)

On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves <bmr at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/03/2012 08:10 AM, Joel Rees wrote:
>> On Tue, Apr 3, 2012 at 3:27 PM, Tim <ignored_mailbox at yahoo.com.au>
>> wrote: s/some/a lot of/
>>
>> if you set it up right.
>
> It can still do a fair amount of nasty stuff.
>
>> "xhost local:<subuser-id>; sudo -u <subuser-id>" does pretty well
>> with current applications.
>
> 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?

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

> There have been vulnerabilities of this kind in
> the past that allowed an attacker to quickly gain a root shell given
> the ability to connect to the X server.

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?

>> Now, if I'm going to my bank site, I do log out and log in as a
>> different user, just to be extra safe.

Now, I want to make it clear that I recognize that, if the bad guys
have succeeded in taking over the bank site, restricting my internet
banking access to an account that I do nothing else with doesn't
protect me, relative to that bank. It may keep up some speed bumps and
low walls relative to attacks on my machine, of course.

> I think you'd be better off taking a look at Daniel Walsh's blog posts
> on confining X applications with the SELinux sandbox. The first post
> introduces and explains the general sandbox concept:

I am familiar with the sandbox principle, in several versions, thank
you. Not that one more point of view or version ever hurt.

> http://danwalsh.livejournal.com/28545.html

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.

> And the follow up looks at extending this to untrusted X applications
> using a temporary xguest account (with dynamic $HOME and $TMP) and the
> Xephyr X-on-X server to provide much stronger separation between the
> sandbox and the rest of the system:
>
> http://danwalsh.livejournal.com/31146.html

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.

> Fedora already provides contexts to use with the sandbox such as
> sandbox_x_t, sandbox_web_t, sandbox_net_t etc. depending on the
> particular resources you want to allow the sandbox to access.

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,

> The post discusses future improvements to simplify retrieving files
> from the sandbox when the application exits but I'm not sure of the
> current status of that work.

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 more
complicated SELinux, especially in the patterns by which the tools to
set policy are run.

I'm going to prefer to trust tools I can understand.

--
Joel Rees


More information about the users mailing list