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

[Sean Middleditch <elanthis awesomeplay com>]

On Thu, 2005-01-13 at 23:51 +0000, Mike Hearn wrote:
> > It's not just protecting users from each other.  It's protecting users
> > from themselves.  There are, quite frankly, people who just don't learn.
> 
> OK so what you're saying is some users need a dedicated admin to ensure
> they don't blow up their own (?) property. This implies two things to me:
> 
> 1) The people you're thinking of are not actually in the home setup
>    scenario I originally described, they're actually in a mini managed
>    network of 1 ;)

I guess that's one way of putting it.  Given that this is a *home* setup
that was constructed by a very computer inexperienced person (my father)
for a computer inexperienced person (my sister and mother) with only
occasional input from me when something breaks, I'd say that trying to
claim that your described scenario is important enough to care about
while this one isn't is a bit of a stretch.

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.

> 
> The situation where it's not good is where you don't actually have an
> administrator. Like single user machines, like families without a resident
> "i'll protect you" admin dude, etc

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.

You mentioned that below, though, so I guess we're probably arguing over
nothing at this point.  ;-)

> > Right, to an extent.  I still wouldn't want them to have the equivalent
> > of root access.  I don't run as root as my Linux boxes even though I
> > fully have that option.  Even an experienced user can make a mistake,
> > and by putting barriers between the user and destructive capabilities is
> > useful.
> 
> 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...?

> 
> > That barrier doesn't *have* to be a password box.  gnomesu or
> > whatever
> > could very well just popup an "This action could be destructive blah
> > blah.  [Cancel] [Eat My Baby]" dialog and run the target app as root
> > based on that.
> 
> 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.

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.

> 
> > There's nothing about Linux or the UNIX architecture that stops that.
> > It's as simple as a small change to gnomesu or consolehelper or
> > whatever.
> 
> I'm not sure: it means the authentication system is now fulfilling a
> secondary role as a safety net which it was never designed for. Is Gnomesu
> going to be modified for each potentially destructive action? How do you
> avoid Windows disease where deleting a shortcut from the desktop gives you
> N warnings about how that doesn't uninstall the app, is potentially
> harmful etc?

Gnomesu wouldn't be modified for each action.  You'd definitely want to
use consolehelper for a system like you're describing.  Take a look at
what consolehelper is actually capable of.  With a few slight
modifications it could easily handle your use case.

> 
> I think some kind of dedicated safety system would work better than
> expecting users to think "Hmm, have I really thought this through?" when
> faced with a password dialog. 
> 
> > The existence of user accounts is an implementation detail.  A useful
> > one.  You can easily slap a Win98-like user interaction model on a Linux
> > box.
> 
> Sure user accounts are fine. But in a true home setup (not a managed
> desktop parading as a home setup) nobody should have to type in passwords.
> There should be no need for each user who has access to the system (family
> member, whatever) to memorize the root password so they can install new
> login screen themes or install new software.

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.

> een the extremes.
> >> 
> >> Ah well now you're saying that every computer should have an
> >> administrator. That's fine for homes with geeks in. For single user
> > 
> > Every computer *does* have an administrator.  Some just have far more
> > talented admins than others.  That's where defaults come in.  Defaults
> > should handle the case where the administrator is very very unskilled;
> > say, my grandmother.  if the system design assumes there is no
> > administrator, however, then when someone who *is* skilled comes in,
> > they find the system hamstrung.
> 
> That's like saying every car has a mechanic, and grandma is just a very
> untalented mechanic. I don't think it makes much sense. I also don't see

I don't really agree at all, but I guess we shouldn't argue over
analogies and terminology... ~_^


> 
> > Linux can have "easy for unskilled home user" defaults while still
> > retaining its full access control (or better access control through MAC
> > and so on) for users that wish to utilize it.
> 
> IMHO easy for unskilled user means no password/root prompts for the
> following (at minimum):

> - Configuring the system (hardware, network, time/date, firewall)
> - Installing new software
> - Installing new themes systemwide (variant on the above)
> - Initiating network connections
> - Mounting drives/remote shares
> - <fill in pet root hate here>

A password isn't necessary for any of that if you just tweak a few
thigns here and there.  No new OS paradigm required.

> 
> At that point you've relaxed UNIX security so much that it's effectively
> non-existant and you need MAC to provide compromise damage control. 

Quite true.  Slap SELinux on it and you're set.  ~_^

> 
> Clearly the same codebase needs to easily adapt to both managed desktops
> where lots of actions need root password (but in that case GNOME should
> not even show these options to non-root users IMHO, not even in the menus)
> and the non-managed home desktop where nothing should produce a password
> prompt but everything is available and security is effectively transparent.
> 
> I guess using a library to abstract that out makes as much sense as having
> two development streams ... not sure. It's late. I think you should write
> up this discussion in the Wiki like Jeff said, I'll help if you'd like me
> to, otherwise this wonderful discussion will get lost or forgotten about.

OK.  Sorry if I spun this discussion around in circles for not quite
seeing eye-to-eye with you on it.  ;-)

> 
> thanks -mike
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>