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

(woops, missed the user list)

On Tue, Apr 3, 2012 at 5:47 PM, Bryn M. Reeves <bmr@xxxxxxxxxx> wrote:
Hash: SHA1

On 04/03/2012 08:10 AM, Joel Rees wrote:
On Tue, Apr 3, 2012 at 3:27 PM, Tim <ignored_mailbox@xxxxxxxxxxxx>
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.

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:

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

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
users mailing list
To unsubscribe or change subscription options:
Have a question? Ask away: