Re: users, "private" groups, and The Unix Way (was, Re: Is it me or is it sudo?)
by Joel Rees
On Wed, Apr 4, 2012 at 2:05 AM, Bryn M. Reeves <bmr(a)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
12 years
17 will not update: NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
by SES
See below- Fedora 17 keeps crashing on update attempts as follows:
Thx!
SES
--
Test Transaction Errors:
file /usr/share/locale/be/LC_MESSAGES/nm-applet.mo conflicts between
attempted installs of nm-connection-editor-0.9.4.1-1.fc17.x86_64 and
NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
file /usr/share/locale/bg/LC_MESSAGES/nm-applet.mo conflicts between
attempted installs of nm-connection-editor-0.9.4.1-1.fc17.x86_64 and
NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
file /usr/share/locale/ca/LC_MESSAGES/nm-applet.mo conflicts between
attempted installs of nm-connection-editor-0.9.4.1-1.fc17.x86_64 and
NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
file /usr/share/locale/ca(a)valencia/LC_MESSAGES/nm-applet.mo conflicts
between attempted installs of See
nm-connection-editor-0.9.4.1-1.fc17.x86_64 and
NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
file /usr/share/locale/crh/LC_MESSAGES/nm-applet.mo conflicts between
attempted installs of nm-connection-editor-0.9.4.1-1.fc17.x86_64 and
NetworkManager-1:0.9.4.0-1.git20120328.fc17.x86_64
file /usr/share/locale/da/LC_MES...
------------------------------------------------------
12 years
console transparency 'not supported'
by Mark Haney
I just finished getting Fedora configured on my netbook and wanted to
setup my consoles with a slightly transparent background. But when I go
to do so, I get a message that my desktop appears not to support
transparency. Has anyone seen this before? I know transparency works
on this hardware since I had it configured in Kubuntu on this box.
Is there some setting I need to change?
--
Mark Haney
Software Developer/Consultant
AB Emblem
markh(a)abemblem.com
Linux marius.homelinux 3.3.0-4.fc16.x86_64 GNU/Linux
12 years
soft link vs. direct efficiency
by SternData
I've added a second disk to my system (/dev/sdb1) and moved a directory
from my home folder there. I then created a soft link to the new directory:
ln -s /mnt/sdb1/mystuff/folderA folderA
When I'm copying files to it, is there any loss of efficiency (in a
measurable sense) between
rsync /path/to/folderB ~/folderA and
rsync /path/to/folderB /mnt/sdb1/mystuff/folderA
--
-- Steve
12 years
Re: Mobile 'ish Desktop (Read GNOME 3) vs Traditional, Desktop, (Read KDE
by Joe Feely
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> On 04/03/2012 08:03 PM, Joe Feely wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/04/12 13:00, users-request(a)lists.fedoraproject.org wrote:
>>> Mobile 'ish Desktop (Read GNOME 3) vs Traditional Desktop
>>> (Read KDE
>> I have gone the XFCE route, but failing that I would have picked the
>> KDE route.
>>
>>
>>
>>
>>
> What made you opting that route?
I liked Gnome 2, it just allowed me to work in a way I liked (i.e. my
preference), I found Gnome 3 wouldn't easily accommodate my preferences.
XFCE is close enough to Gnome 2 and closer than anything else I've
tried. I used KDE for a short time, well before KDE 4, and found that
okay, but I simply preferred the look and feel of Gnome 2.
I like to put certain apps in certain workspaces and like them to stay
there. I found M$ Windows (long time ago, maybe it's caught up) way too
frustrating with having to minimise loads of windows just to make way
for what I wanted to do next.
If you're asking for my view, the above is part of it. If you're asking
for which way to go, then go play with a bunch of them (as seems to be
what many have suggested in previous postings).
Have fun,
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPeyY6AAoJEGgCZ2pTomv8Z2YIALYzIOJ725iJf4iT9Z/bqSoI
H30nml8VNI91DMUZuD21iWM3QD4fICXPbMYPYf/bTfNUNmSPv5871jjwgAKm1UAf
e32BVEZD8v39o4yHOOiKWCE4X52MVyWz9swInZzsquOjmmYi+vyUvonspJBzZu2m
mAJkBjUKI8pPxaOwLCTaMq8NZtcvep9du+AAfYM+rlLW7LUEnc6bF00aMJK6ZTsd
IjvLYQJGBAQEDzes/dvuxL+5Ah78RXPNG6gkOiwKNlq8uUaQ3i6zvxIBx9/FhPP6
/BN3rqEUAcz6xwKZrG5KSW1l0ptQ0TwRyicbLv64qzBPHvN43L8rmIyKE7YNk90=
=YAlV
-----END PGP SIGNATURE-----
12 years
users, "private" groups, and The Unix Way (was, Re: Is it me or is it sudo?)
by Joel Rees
On Sat, Mar 31, 2012 at 7:04 PM, Tim <ignored_mailbox(a)yahoo.com.au> wrote:
> On Fri, 2012-03-30 at 20:39 +0100, James Wilkinson wrote:
>> From there, it follows that the easiest way to do this is to make 002
>> the default umask, which means that all new files and directories
>> created by normal users have these permissions. That means that if you
>> want files that only their owner can write to, you need a per-user
>> group.
>
> It always struck me that personal files ought to have no group or world
> permissions set by default. If you wanted your files to have those
> extra permission set, then it ought to be done as a deliberate choice.
Maybe "user-id" is mis-named. There are sure a lot of people who tend
to see "user-id" and expect the one-to-one correspondence. I know the
conflation caused me some frustration back in college, and I'm not
sure I got it properly worked out until I put together a few openbsd
systems.
Anyway, it should be clear that a system administrator should not be
logged in as a system administrator when he or she is just writing an
e-mail scheduling meetings or something. But even ordinary (human)
users should not be surfing the web as the user they logged in as, and
I'm not talking about keeping my boss from checking my cache for
visits to slashdot or whatever.
As the system administrator for my home box, I want to be able to log
in as a normal user that is not tainted by my the web sites I visited
last time I logged in. That means I have a separate administrator
user.
I want one user-id/group-id pair for each bank I have to visit, so
that, even if we can't get the banks to use special-purpose browsers
for the money transactions, I can protect the bank data from the guys
that want to mine my data for their gain, including the other banks.
(Special purpose browsers are preferred, of course.)
And when I need to go surfing through blogs for news, I don't want to
do that with the user I logged in as. Even if/when we can get rid of
the sloppy programming practices Microsoft and their ilk promote, we
can't be sure we have every hole plugged, so it's just going to be
safer to do that as a user that isn't allowed to log in. That means
that, even though I log out of my "worker" user and log back in as my
"play" user, I still want to spawn a nologin user from there to surf.
(This is not pure paranoia. I checked out a company for a job and
discovered that Google had flagged their site as containing malware,
and the guy who ran the company did not have the financial means or
motivation to hire someone to clean the server up. Scared of having to
move off the vulnerable tools he was using, trying to meet a market
window that was fast disappearing, all the excuses.)
Incidentally, I'm doing this much now, using xhost local and sudo. (If
you're curious,
http://reiisi.blogspot.jp/2011/08/simple-sandbox-for-firefox.html
is my blog from when I first got it running. I need to re-write that
explanation, which is part of the reason I'm writing this long-winded
post now. But I still have issues with the input method that I need to
solve. And I need to write some scripts so I don't have to all the
tweaks by hand every time.)
And I glue it together with per-user groups. Without per-user groups,
I would have to go through serious admin-level contortions to grab a
download. Does that make sense?
--
Joel Rees
12 years, 1 month
Re: Mobile 'ish Desktop (Read GNOME 3) vs Traditional Desktop, (Read KDE
by Joe Feely
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/04/12 13:00, users-request(a)lists.fedoraproject.org wrote:
> Mobile 'ish Desktop (Read GNOME 3) vs Traditional Desktop
> (Read KDE
I have gone the XFCE route, but failing that I would have picked the KDE
route.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPewMkAAoJEGgCZ2pTomv894sIAKwUPFZ+pbFGh1gEQrQ1N6dE
sVGikUCczyJhMYC/EFwM9DYHHVf1grUPm2AeLk4G3D/Rod25wvZrO/MI2TLCZuTF
CEVDecFIwJJPB9F//O4oFCqowrE7G2gPaNHcMTmaui7/DPDXp/Oannn7xptVuifh
W8jxwbfXGiA3wQkVpLQWcFf8K10Nb5KHe/+ChObfRI4CepWPJdX5OW62HLAyV9dJ
G1GTVhGdfHew9D8YvFeXde+Y8ecRjqcgQMybd8+GKqmcfAfnklZAYh56uP8kl5ZR
lBPPkoQ5AD2FjZV41Fc03D+e+lAD3hSHBI4Jyt1poIY/dsScTM+KHVG65tVhSsg=
=hUO4
-----END PGP SIGNATURE-----
12 years, 1 month
Createrepo with local repo
by Frank Murphy
Can I specicify a wildcard for old pks dirs?
cat /etc/yum/pluginconf.d/local.conf
repodir = /nfs/yum/16/i386/_local/packages
oldpackagedirs = /nfs/yum/16/i386/*
(This is where all the 32bit F16 boxes have their yum cache.)
The local repo by itself only has non-feora rpms.
--
Regards,
Frank
"Jack of all, fubars"
12 years, 1 month