-----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/
iEYEARECAAYFAk97LcIACgkQ6YSQoMYUY94nDACglWoJJVR1xBG1aH8fGeLd6VsF
LG0AoJKTiIaaMmBQezBpeWD7f728Hc4R
=gEBC
-----END PGP SIGNATURE-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
