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

[Sean Middleditch <elanthis awesomeplay com>]

On Fri, 2005-01-14 at 14:55 +0000, Mike Hearn wrote:
> On Thu, 13 Jan 2005 19:28:08 -0500, Sean Middleditch wrote:
> > 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 ...

Then maybe that should be fixed.  ;-)

Ideally we need a platform to build stuff on.  Perhaps consolehelper, or
something similar, needs to be a part of that platform.

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

The problem is that you are talking about the GUI while also talking
about the implementation.  You can easily make the GUI do *anything* you
want with *any* behavior you want without massively ripping out all the
security checks in the base OS.

i.e., Let the Install Software GUI run without prompts *if* that's how
the machine is configured.  That's all the GUI.  Under the hood you can
still keep distinct privileges.  Sure, on your Home system any user can
run Install Software.  However, because only that application has the
MAC controls to put files in /usr, you don't have to worry about random
virus A modifying /usr.  You also give the user the option to be
protected with package signing.

Say you download a trojan on your Home system and run it.  It can't
modify the system because the MAC controls say it can't.  Yes, the
trojan can run Install Software *on your system* because you are an
ignorant user.  Your friend, however, knows about package signing
because he's been educated so he doesn't install the trojan with Install
Packages.

If you rip out the security under the GUI then educating users becomes
pointless because you no longer *need* a social engineering attack since
you've ripped out all the technical security.  It doesn't matter if your
friend is smart about installing untrusted binaries or not since they
can just install themselves without even asking him.

If you keep the system secure and paper over it with the GUI then you
can get both your Home system with low-security and my system with good
security with *no* code changes or recompiling or repackaging needed - I
just go into the system setting and click "Software Installation
Requires Password: [secret]" and the system just starts working securely
(as in, it allows me to make intelligent choices.)

Really, my whole argument isn't against your UI - you're right that for
the average home user your UI is probably better.  I'm just saying that
you simply do not have to gut the OS to get the UI.  Just set rpm setuid
and you have your "anyone can install software" system with nothing more
than a single setting (the setuid bit) - no GUI/OS/code changes are even
necessary.

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

That's a UI design bug which can be fixed without massive changes to the
OS.

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

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

Like I said above, the *really* quick implementation is to just setuid
any binaries that need elevated privileges.  Now any user can do
anything.  You can ship a system like that and knowledgeable users can
just remove the setuid bit and get security without hurting other users'
systems or needing code changes.

That's basically what consolehelper is.  It's a setuid app that invokes
another binary with privileges.  Consolehelper is cool since it allows
you to set policy for each binary - for example, I can tell
consolehelper that Install Software requires the SELinux sysadm_r role
(to stop a trojan from silently invoking it, for example), tell it that
time change requires root password (because you're a BOFH), tell it that
Network Config can be run by anyone but Bob (will he ever stop deleting
your wireless settings?), and tell it that User Manager can be run by
anyone at anytime (the ultimate security hole!).

Your ideal Home system basically already exits, you just haven't
configured it yet.  ;-)  Just ship your system with the consolehelper
policy set full-open and you have a Home system.  Add an app for
selecting from a number of policy profiles and you can let users who
know how to effectively use passwords and such and now you have one
system that fits multiple needs and levels of user experience without
needing different code/binaries/ISOs for each.

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