Re: More desktop security thoughts (was Re: GNOME privilege library)

[Mike Hearn <mike navi cx>]

On Thu, 13 Jan 2005 19:28:08 -0500, Sean Middleditch wrote:
> Clarifying, I'm not saying that your ideas are wrong, just making it
> clear that it's not black and white.  There are different levels of home
> users and different people have different needs and that there are home
> users that want and need restrictions on user accounts.

Well, alright, you're probably correct. Things are very rarely black and
white.

And yeah if it wasn't already obvious I'm kind of making this up as I go
along :) I'm not even sure if I convinced myself yet ... but we might as
well thrash out the alternatives.

> Right.  My point is basically just to make sure that you don't hamstring
> one use case while designing for the other.  Don't try to gut out the
> entire UNIX access control system when really *all* you need to do is
> modify a few bits and pieces.  On a Red Hat system you could obtain
> exactly what you're looking for by just modifying some consolehelper
> settings and GDM settings, for example.

Well maybe. Consolehelper doesn't help autopackage or Wine though ...
those are just the projects I happen to be involved with. I think once you
start down that road the number of tweaks just gets higher and higher, and
each time a tweak is proposed that'll mean a massive flamewar over the
security merits of that particular permission (thread priorities, write
access to /usr/lib, whatever). If you do it all at once and say "This is
the way forward" all those edge cases disappear and you can have one
massive flamewar instead of lots of big flamewars :)

>> Well, root is being used to do different things here. It's being used
>> as a safety net to stop you accidentally typing "rm -rf /" and it's
>> being used as a hack around the fact that desktop usability in general
>> (Windows/Mac too I guess) is so pathetic that users run the risk of
>> destroying something they actually own.
> 
> So it's better to just not allow users to do anything that might
> possibly destroy data...?

Sure, why not? There's always the command line for people who really need
low level control. And actually that's quite nice: it means we can provide
a solid, reliable, chewable-and-waterproof GUI that users can feel
confident in and still have very fine degree of control via the command
line for power users.

> > I'm confused, gnomesu is about asking the user for the root password
> > right? Not confirming arbitrary actions which might be potentially
> > harmful. That's Nautilus' job, or the panels, or ....
> 
> No, it *definitely* is not.  If a process needs privilege the gateway
> between the unprivileged and privileged processed must be well defined.
> If Nautilus was responsible for confirming with the user before running
> a command with superuser-like privileges then as soon as you want to
> change the access model you have to modify Nautilus plus every other
> application around.

OK, sure, but there are harmful actions you can do in regular GNOME that
don't require authentication (like removing nautilus from the session
manager ...). This seems to be a specialisation of a more general thing,
that of providing a customisable level of safeties so users who are very
confident don't get bugged a lot, and the Laurel-and-Hardy type users who
managed to destroy everything they touch have lots of safety warnings.

Now I'm talking about some generic GSafety system though which is a topic
for another time :)

> That's the whole point of my original proposal.  Nautilus needs to do
> something that requires privilege like modifying a file in /usr (bad
> example, but you get the point).  Nautilus just uses an abstract API to
> invoke a backend to do this work.  On your home system that abstraction
> layer (a setuid helper that launched the backend, for example) would
> just ask for confirmation.  On my sister's system it would ask for an
> admin password that only I or her parents know.  On my system it would
> ask for my account's password because I'm slightly paranoid.  On a
> system at NASA it would initiate a full biometric scan, ten passphrase
> challenge, voice recognition scan, and cavity search.

OK, this seems to make sense. I haven't really thought much about
implementation :D

> Yes, exactly.  That's what I said about mimicing Win98.  You can remove
> every need to ever type a password on Linux *without* getting rid of
> root or user accounts.  It's *not* difficult and does *not* require any
> massive reengineering.  Just small relatively minor configuration
> tweaks.  If you are making an OS for home users you'd just make those
> configurations the defaults.

Yes, maybe .... I'm not convinced but never tried it myself so don't
really know what I'm talking about :)
 
thanks -mike