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

[Joel Rees]

On Wed, Apr 4, 2012 at 2:05 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
> -----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).

Exactly.


I guess, though, that I am willing to use a separate login on those
sites, rather than separate hardware on a separate segment of the
internal network at home.  At work, it would depend on what I'm
working on.

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

I assume that payloads that target the X vulnerability are
significantly fewer. Not perfect, but you match the measures with the
threat and your budget.

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

Woops. Guess I was forgetting that Fedora is not maintaining its own X11.

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

Well, from where I sit, I have to guess that the openbsd engineers
doing the aperture work are a bit more on top of the technical details
than you. And I think you admit that. That's the gap I'm talking
about. It is a relatively high wall, compared to some walls.

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

But tell me about real exploits.

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

Theo is dead right on that. Intel failed us on the processor design
and only recently accepted the responsibility of providing MMU
functions to enable making executable store non-writeable. There's a
long way to go there, and, while the old 68K had the MMU capability in
the architecture, competing with INTEL pushed the industry to fail to
support it in the circuitry external to the CPU.

And then, when the graphics processor manufacturers started up, there
was no pressure to get it right, and a lot of pressure to not bother.
Excessive competition is as much a sin as deliberate fraud. As is
complacency (and collaboration) on the part of the OS vendors. (I say
plural because there were alternatives to Microsoft in the mid-80s.)

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

Since soft words have failed to motivate the vendors, hard words are necessary.

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

Wish I had time. I don't really have time to be writing this.

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

I'm not going to log out and log back into my play account to look at
those. Sorry. But, just guessing, from the numbers I've looked at in
the past, I'm going to guess that the studies referred to there have
certain logical flaws, like failing to follow the numbers long enough,
and unjustifiable assumptions about the curve on the numbers on the
branch not taken.

One anecdote for you (not anecdote for me): the guy in the bmw coming
onto the freeway from the ramp beside me, I guess he was twenty over
the speed limit by the time he left the ramp, and he was wearing a
seatbelt. (I could see the shoulder strap. My eyes were better back
then.) And if I hadn't been looking sharp, he would have ended up off
the freeway on one side, and who knows where I would have been. I have
seen a bit of that, and I have noticed that I myself tend to let
myself get distracted more easily when I have a seatbelt on.

On not saying seatbelts are bad, I'm saying the laws are bad and
ignore reality. Should not let insurance companies make defacto law,
it's the same issue as letting OS companies sell stuff they aren't
willing to guarantee at any level and try to enforce user behavior by
punishment. Tangentially topical because it's thinking like that which
got the industry into the mess it's in.

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

X11 is way too large. Firefox is way too large.

The kernel is way too large. That's why I would prefer to use the
user/group/other model instead of adding what amounts to ACLs, etc.

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

Okay, not the ACLs as specified by some "classic" definition, but the
same class of beast, near as I can tell. Well, I tend to group this
kind of thing in with capabilities.

They all use lists of some sort to punch holes in the user/group/other
model, instead of using the user/group/other model to model what's
actually going on.

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

And?

You can use the user/group/other model in combination with sudo to
achieve the same sort of thing.

Have to re-write applications to get them to respond correctly, but
the same holds true for

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

Which is the reason I tend to think of them as the same thing.

I have to admit, sometimes I wish I could just throw a label on a
file: John can see this, too. But then I remember: if I had a
cardboard box, labeled it with a "John can read this, too." and set it
out on the porch, well, ...

You have to construct the labels. You have to have policies. The
policies tend not to be constructed on the user/group/other model. And
then everything tends to get really confused, as to who is supposed to
own what.

Better to encrypt it and send it to John in an e-mail. Or if we both
have to have regular access, construct a proper box, so to speak, not
just labeled, but complete with it's own user and group: jnjp for
"Joel and John Project" or something.

> Xattrs are also used for ACLs in many file
> systems so that may be where the confusion arises.

Okay. The machinery is a little different. Maybe a bit cleaner. But
why do we have to have policies? (And what should the policies be
modeled on?) And why should the labels get priority, and when? More to
the point, how do I remember the conflict resolution rules?

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

More opportunity for confusion and rules conflicts. Yeah, I suppose
I'm going to have a hard time getting excited about that.

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

(Where can I stick a note to myself to read that when I have time?)

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

My objective is role separation. Unless an employer tells me to do
otherwise, when I need more than that, I'm going to use separate
hardware.

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

That's another option, although I have some reservations about the
wall between the VM and the host OS. It's a little disappointing to
see the hardware requirements for that going up, but not surprising.

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

The same could be said for the user/group/other model, with the nice
advantage that the user/group/other model has a fairly strong
theoretical basis.

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

Eight years is a long time in this industry, in this respect. Thirty
years down the road, yeah, the difference won't be so great.

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

Except the one you're letting slide: What can the user do with it?

>> 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, labels, capabilities, policies, they all are imposed on the
simple file system models (plural). The all add complex interactions
with the underlying model. Which wouldn't be so bad if the real
complexities weren't in what the user is doing and how the machine
responds.

The real complexities arise when you get the machinery trying to
figure out what the user wants to do. In the case of the graphics
stuff, that's pretty tame, still pretty close to a state machine. In
the case of the file system, users do what they please. That's two
levels of complexity beyond what graphics hardware has to respond to.

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

I'm sure the tools are improving. I hope they do. But I expect, at the
end of the road, to see the policies converge back to the
user/group/other model. That's why I'm counter-motivated when it comes
to figuring out SELinux. And why I'm going to be working on tools to
do the same thing in simple user/group/other permissions, with sudo.

By the way, thanks for the conversation. As I admitted, I'm going to
eventually have to figure out SELinux (and actual ACLs, too, much to
my disgust), and you are helping me get some footholds. (Sometimes
argument is less about disagreeing than about trying to make sense of
things.)

--
Joel Rees