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

[Joel Rees]

On Tue, Apr 3, 2012 at 10:24 PM, Bryn M. Reeves <bmr at redhat.com> wrote:
> -----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.

Good point. I don't visit those sites, and it's important for me to
mention that. No p0rn, period, and many of the moral reasons are in
fact parallels of the technical reasons.

Well, sometimes I have to go to some sites that I don't really trust
that much, and I have a user I have dedicated to such uses. For
example, Kickstarter. When I'm logged in there, I'll be on one of my
work users. (Stupid Flash.) But when I'm browsing other projects, many
of the links are offsite, so I shift to the subuser to browse
projects, and if I need to link off-site, I'll log out and log in to
the dedicated play user.

Still not as good as having a separate machine, but better than nothing.

> If your choice is "or do nothing and run them in the normal session"
> then of course there is no difference.

I think there is some difference. If I hit a drive-by when I'm
browsing via a sub-user, for instance, the malicious payload will be
in the subuser's directory tree. Again not perfect, but a bit of a
higher wall than a speed bump.

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

Yeah.

> 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).

License issues? Getting the source should be now problem.

> 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".

What he means by that is a bit different from what you would mean by that.

True, there are ways through that aperture, or around, but it's a bit
of a higher wall than a speedbump. Would take some serious programming
to defeat, enough so that social engineering or bruteforcing tend to
be preferred. Unless you have someone specifically targeting your
network, in which case, you really have to restrict what you do on
your workstations.

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

Yeah, it's going to be relatively slow. But it would be nice to have
that as an option. (Most of what I do would not suffer significantly.)

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

Kind of like seatbelts. You have to regularly ask yourself if they
encourage dangerous driving, and check your habits if you're getting
sloppy.

> This is the
> point of sandbox -X.

Which would be nice if I trusted ACLs.

>> 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).

Wait. Doesn't provide or doesn't use?

If neither, how does it implement those policies that I never can get right?

I thought those policies were just a way to compile those lousy ACLs
so you wouldn't be spending more time setting the ACLs than doing
actual work.

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

Per-process could be an interesting, might be able to combine that
with other things I do.

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

Well, if I were inventing, that would be one thing. I'm just trying to
apply old methods that people who didn't understand the user/group
model in Unix have cast aside.

> 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

Glad it makes sense to you.

To me, it seems like a lot of extra effort just to get back to the
point where good user/group policy would get you, if you were willing
to use per-user groups correctly, and if your admin were willing to do
such things as set up users/groups that corresponded to such things as
projects, and to user activities that need to be separated out.

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

X11 has been around a lot longer than that. So has sudo. And, of
course, so has per-user groups.

> The SELinux folks I know are also very responsive and helpful when
> dealing with user problems.

We would hope so.

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

Volume of source is not the issue.

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

But the interface to a graphics unit is fairly well defined.

The interface to a user's file system is not. That's where the
complexity SELinux is trying to deal with comes in.

The user/group/other model provides a framework that is workable for
pretty much any resource you need to make accessible in a computer
system. It allows some stupid mistakes, but the framework is sound.

ACLs require policies to use effectively (and safely), and those
policies, when we finish tuning them, are going to turn into a
parallel of the user/group/other model.

One good thing that will come out of it, more people will understand
the underlying math. I hope.

--
Joel Rees