Problems of a desktop Linux distribution GUI sudo

[Tzafrir Cohen]

On Tue, Jun 15, 2010 at 03:02:28AM -0700, Elazar Leibovich wrote:
> On Tue, Jun 15, 2010 at 12:44 AM, Oron Peled <oron at actcom.co.il> wrote:
> 
> > On Tuesday, 15 בJune 2010 09:12:53 Elazar Leibovich wrote:
> > > Thanks for the long and detailed reply!
> >
> > Yes, but you (probabely by mistake) replied to me only.
> > I reply to the mailing list with your full content, so
> > the context is not lost.
> >
> 
> I apologize, but at least it's much better than doing the opposite...
> 
> 
> > > Just to make sure I got you correctly, you're saying that no GUI app
> > should
> > > ask for root privileges ever, and only known application should use root
> > > privileges, GUI applications would then only interface them (either
> > through
> > > socket, or by allowing anyone to sudo this specific application).
> >
> > Generally yes.
> >
> > > That's covers installation related software, but what about other
> > software
> > > which needs root privileges? Say I want to run gparted? I don't want to
> > run
> > > a gparted server all day long just for the time I need to run it, and I
> > do
> > > want to be able to run it occasionally.
> >
> > There is no problem with activation on demand (with D-Bus it's a piece
> > of cake).
> >
> > What I say is that new mechanisms have split implementation:
> >  - A priviledged bussiness logic
> >  - A non-priviledged UI
> >
> > BTW: this is a classic separation between interface and implementation
> >     and directly leads to other, non-security-related, advantages
> >     (e.g: multiple interfaces (console, GUI, Web-based) to the same
> >      bussiness logic).
> >
> 
> I'm all for separation between UI and implementation. However if I
> understand you correctly you suggest that, say, gparted authors will NOT
> write the implementation code which needs root access.
> I don't think it's possible to include gazillion services for each possible
> application need. The software must request somehow permission to run its
> root-depending implementation.

What's the problem with that? The code size is not an issue. It's not
much more than parted itself (it can use libparted). It does not have to
run all the time: you may ask dbus to start it only when someone
actually asks for it.

> 
> >
> > > Vista authentication model still works, I'll be sure I'm giving root
> > > permissions to gparted and not to something that looks like gparted.
> > > (The flaws you mentioned in the *current* Vista model are known, but I
> > > believe some could be addressed, some flaws you mentioned are inherent to
> > > Windows in general, and to the sudo-like mechanism it applies).
> >
> > I'm the last to pretend being a Windows expert. However, the latest
> > security related happenings in Vista-7, demonstrate that not much was
> > changed from Vista (other than some colored cellophane and few more,
> > much needed, drivers and bug-fixes).
> >

 
> > > BTW please note that authentication don't have to be done with crypto!
> > > Unwritable file paths could do as well. If for instance you'll only allow
> > > programs in /usr/bin/* to ask for root privileges, and the user will see
> > the
> > > full path of the software asking for root privileges, it provides enough
> > > authentication. The idea is to know who's asking for root relying on
> > things
> > > which are more secure than the software icon, it doesn't have to be
> > crypto.
> >
> > You got confused:
> >  - It's not the user that need to verify that the program is "good"
> >  - It's the program that need to verify that the *user* is authorized
> >
> >  We're indeed talking about different threat models.
> You're talking about securing a desktop box in a typical corporate
> environment. Indeed in this case the user permissions must be checked each
> and every time he's trying to execute a program.

Nope. It applies equally well for a desktop system. Same mechanism,
different policy.

> I'm (and if I understand correctly, Microsoft also considers this model)
> talking about securing a desktop user which owns the computer.
> He always have full control, if he can touch the keyboard - he's OK.

A sanity check. The simplest thing to do would be to run everything as
root. The system we want to have should be more secure but only
marginally less convinient.

> However he wishes to run various softwares from various sources, and we need
> to minimize the risks for him.  The typical PC user IMHO wants to install
> software from various untrusted sources. Even I'm installing various
> software from various sources and hope for good, I need Adobe Flash I use
> Google Chrome, I use IntelliJ Idea and Sun's Java, those are not available
> from Ubuntu. And by all means I don't think Ubuntu should package all
> software in the universe. It should be the developers' job.
> I think that if Linux becomes very popular it will have to happen. I tried
> to convince friends many times not to install random software from the
> internet on their Windows desktops because this tends to make troubles, but
> none of them agreed. I even installed virtualbox for them to try the random
> software on it, but it didn't help. They need that. You can't argue with
> that.

It's long since I've seen anybody using the properitary Netscape browser
on Linux. For some strange reason people just used Mozilla.

OpenJDK comes now with every distribution. Likewise is Chromium.

Google's packaging of Chrome has a nice touch in it: it manipulates your
package repository (just in case you "accidentally" removed it).

This only indicates that if you have installed an untrusted package, you
have already given the attacker potential root permissions. I have no
idea what you're trying to make more "secure".

> 
> There are various things which can be done, but the first thing we do, is
> tell him - never run as root. All his files are in danger, as well as his
> various email accounts. However nothing can pollute his boot record or
> system files or kernel.

Unless that package installed a nice little cron script that runs as
root.

> However sometimes the user want to run some of his untrusted software as
> root, and we want to allow him to do that in a relatively secure way.

You have a strange threat model. You want to both protect the user and
give the user the all rope to hang himself.

> 
> One thing we should NOT do is to force the user to be to authorizing the
> update manager to run as root, and allow any program to look like the update
> manager.

Maybe the rule should be: don't ask the user to re-authenticate for no
good reason? The user is already authenticated, after all.

Hmm... now, I wonder if this is already implemented somewhere.

> If this wouldn't happen the user might have many viruses - but all are in
> user space.

Viruses? I owuldn't worry about viruses. I'm more worried about worms
and zombies.

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend