FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-03-2012, 03:56 PM
Joel Rees
 
Default users, "private" groups, and The Unix Way (was, Is it me or is it sudo?)

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAr43iPhMXwzGZ4Be_0vxCoPS4ufy4rxsgk9zJ349vsELR358 w@mail.gmail.com">http://lists.debian.org/CAAr43iPhMXwzGZ4Be_0vxCoPS4ufy4rxsgk9zJ349vsELR358 w@mail.gmail.com
 
Old 04-03-2012, 04:00 PM
Joel Rees
 
Default users, "private" groups, and The Unix Way (was, Is it me or is it sudo?)

Sorry about the cross-post, guys. Still not used to Google's webmail,
didn't look closely enough at the address it gave me. I need glasses.
And other bad excuses.

:-(

On Wed, Apr 4, 2012 at 12:56 AM, Joel Rees <joel.rees@gmail.com> wrote:
> On Tue, Apr 3, 2012 at 10:24 PM, Bryn M. Reeves <bmr@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@redhat.com>
>>> wrote:
[...]


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAr43iMm3oeAoffvZrG6u9q399SYWJPuKL6kpfPVRU0OQUp60 g@mail.gmail.com">http://lists.debian.org/CAAr43iMm3oeAoffvZrG6u9q399SYWJPuKL6kpfPVRU0OQUp60 g@mail.gmail.com
 
Old 04-03-2012, 05:05 PM
"Bryn M. Reeves"
 
Default users, "private" groups, and The Unix Way (was, Is it me or is it sudo?)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/03/2012 04:56 PM, Joel Rees wrote:
> 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

There are a lot of perfectly family-friendly websites whose
administrators I do not trust as far as I could throw them (even if I
knew where they were).

> in the subuser's directory tree. Again not perfect, but a bit of a
> higher wall than a speed bump.

If the payload targets an X vulnerability there is no difference.

> License issues? Getting the source should be now problem.

"Upstream first" - Fedora goes out of its way to get new features into
the distribution by getting them into the projects it packages
upstream (often by doing the work upstream).

There are occasional exceptions but it's very unusual for Fedora to
take a large set of changes from another downstream packager before
they get merged.

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

Thank you for enlightening as to what I meant (although what you
assume I mean by that may not be the same as what I actually meant
when I wrote it).

> 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

That's not the case at all. It's just a more constrained interface to
the same thing (and Linux is fairly restrictive about that these days
too). A smaller attack surface doesn't mean that you need targeted
attacks; almost certainly if someone discovered an exploitable flaw in
this it could be developed into an easily deployed local exploit just
like any other.

What I understood from Theo's statement is that while it tightens some
avenues for exploit development the basic model of exposing hardware
to a userspace process (privileged or not) is broken. Not everybody
agrees but there is a lack of a usable alternative right now.

He also goes on to state that X: "violates all the security models you
will hear of in a university class." due to the exposure of the device
registers, memory space and I/O ports to userspace ("drivers in
userspace" model) and that the X developers are "a bunch of shameless
vendor-loving lapdogs who sure are taking their time at solving this
10 year old problem".

I am sure such words would motivate me to help him if I worked on X.

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

There are vesa drivers in Fedora. I have no idea how difficult it
would be to coax them into running unprivileged but if it interests
you you might want to look into it.

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

The evidence base disagrees here. Multiple studies find large declines
in casualty figures following introduction of mandatory seatbelt laws:

http://jech.highwire.org/content/43/3/218.full.pdf
http://tinyurl.com/bu6ymdn [jstor]

> Which would be nice if I trusted ACLs.

But you trust the kernel, Xorg and Firefox which are considerably
larger and more complex beasts? Ok...

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

Not quite: SELinux provides a framework for defining access control
policies based on users, roles and types (aka domains). The policy
defines what actions a given user/role/type combination is permitted
to carry out. Daemons and other confined processes are placed in a
specific domain to limit their access to system resources according to
the policy:

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

You can use this to implement RBAC, MCS, MLS etc.

SELinux contexts are stored along side files in the file system as
extended attributes (xattrs) - i.e. it's label-based rather than
path-based security. Xattrs are also used for ACLs in many file
systems so that may be where the confusion arises.

ACLs usually refer to access control lists - most often file system
ACLs although there are many other uses of the term e.g. BIND DNS ACLs
or Microsoft Windows fs ACLs mapped through Samba/CIFS. An ACL is just
a list of identities and the level of access they are permitted. Fs
ACLs are available with any modern Linux file system and operate
independently from any LSM security framework in use.

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

Check out pam_namespace which does per-session namespaces (and
probably more now, it's been a while). There's a post from Russell
Coker discussing it here:

http://etbe.coker.com.au/2008/12/13/per-process-namespaces-pam-namespace/

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

I still use those methods when I just want role separation (e.g.
"personal" vs. "work" web-browsing) and I think they fit that need
well. I am just not convinced that they buy you much of value when
your objective is isolation for security reasons.

You'd almost be better off keeping a snapshotted "scratch" VM lying
around to fire up for those needs.

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

Think of it this way: at some point you had to learn how Unix users
and groups worked but that was a good investment because afterwards
you could achieve more on the system than you could before. SELinux is
just the same and although a lot of users seem put off at first it's
really not that difficult if you just want to "use" it.

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

X11 has but afaik XFree86 only got going in '92 or so - SELinux has
been around for twelve out of those twenty years.

> Volume of source is not the issue.

When you're dealing with one codebase that is an order of magnitude or
two larger than another you can make some assumptions. Or to look at
it another way compare the documentation and specifications for the
two. X11 is larger and more complex by just about any metric you care
to choose.

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

I'm not sure what you are getting at here? By graphics unit do you
mean the hardware? The APIs? There is great variation in hardware and
great difficulty getting reliable specifications for it. This is why
people spend their time staring at register dumps to write the reverse
engineered nouveau driver. At the API level everything's pretty
standard once you get down to the X11 level but sitting atop that are
any number of frameworks, toolkits, libraries, IPC mechanisms etc.

On the other hand the file system interface is very standardised and
has to comply with a number of standards.

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

I think you might be pleasantly surprised to find out how SELinux
plays out in practice. The idea is that the distribution provide the
policy for the common cases - I've supported very large numbers of
commercial users running SELinux and only a handful had to do any
custom policy administration.

Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk97LcIACgkQ6YSQoMYUY94nDACglWoJJVR1xB G1aH8fGeLd6VsF
LG0AoJKTiIaaMmBQezBpeWD7f728Hc4R
=gEBC
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F7B2DC2.4010107@redhat.com">http://lists.debian.org/4F7B2DC2.4010107@redhat.com
 

Thread Tools




All times are GMT. The time now is 03:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org