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



On Thu, 13 Jan 2005 18:13:49 -0500, Sean Middleditch wrote:
> I was interpreting as "having privileged/unprivileged users" is
> bad.  ;-)

For the home setup yeah, because it implies throwing up password dialogs
everywhere and users having to understand account duality and all kinds
of icky things.

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

2) There is a serious amount of work left to do on computer usability
   in general. Nobody should have to be restricted with computers because
   they might accidentally destroy it! That's like saying I shouldn't be
   able to set the thermostat in my house because I might set it on fire ...

>> The point is in a family/home environment you wouldn't *need* to
>> switch
>> accounts or enter passwords. Your little sister would be able to make
>> the change from her own account.
> 
> No, she very specifically would not.  That's the whole point.

In that case you're administering her computer and this isn't a home
setup, it's a managed desktop which I originally said should have
root/user security and that was a good thing :)

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

>> Now if you think your little sister cannot be trusted with that level
>> of access then this is a different issue - if she's just inexperienced
>> we need a better desktop, if she's deliberately malicious maybe my
>> original idea (which is overly simple I admit) needs adjusting so by
>> default users are trusted then you can mark particular accounts as
>> running in restricted mode or whatever. That's not user vs root though.
>> That's lots of users all with the equivalent of root access, except one
>> or two that are limited in arbitrary ways.
> 
> 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. 

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

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

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.

>> > There is no ideal security.  In some places I don't want separate
>> > users, in some places I want to have a super-user, in some places I
>> > want a password for each distinct task, in some places I want to
>> > assign privileges to accounts, etc.  Letting the system be setup to
>> > the actual needs of the administrator (be that a corporate network or
>> > a tech-savvy big brother) should always be possible.  Trying to come
>> > up with some all-encompassing claim of "home users don't need it" or
>> > "we should only support perfect security" just makes the system
>> > unusable to everyone between 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
how the non-admin case of all users effectively having root access (with
safeties) would make a real admin hamstrung. Also, how often do computers
switch roles like that? If Helen History-Student buys a laptop to write
essays on, is it likely that at some point this will become a managed
desktop? I'm not sure.

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

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. 

> I don't really think there's such a fundamental problem as (I'm
> interpreting) you are making it out to be.  It's more just defaults and
> a few UI bits here and there.
> 
> (Also note that the library/API I proposed would let you swap around
> security models without modifying or recompiling any apps, which might
> make it a lot easier to experiment with and test different models, or
> let you select an appropriate one for the user at install time, etc.)

Yes, very possibly, I haven't really thought about the implementation
details of it yet. Hey, you wanted us to talk UI design right ;)

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.

thanks -mike




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]