Problems of a desktop Linux distribution GUI sudo

[Tzafrir Cohen]

On Mon, Jun 14, 2010 at 09:22:23PM +0300, Elazar Leibovich wrote:
> On Mon, Jun 14, 2010 at 8:41 PM, Tzafrir Cohen <tzafrir at cohens.org.il>wrote:
> 
> > On Mon, Jun 14, 2010 at 08:12:43PM +0300, Elazar Leibovich wrote:
> >
> [snip]
> 
> > > But I'm not interested with extra limitations. I want to allow the user
> > > sudo'ing whatever he wishes, to allow any program to prompt for extra
> > > permissions, but still disallow a malicious software to disguise as a
> > > legitimate software, and trick the user to give it extra privileges.
> >
> > Define "malicious software".
> >
> > For instance, should a script that I wrote be considered "malicious"? A
> > script that root wrote?
> >
> > Depends on the user. He will decide if your script should get root
> privileges. If I were him I'll never give root privileges to anything which
> is not an installer.
> 
> But what shouldn't happen is that *his *script will disguise as your script,
> and will ask for root permissions. I will then give *his* script permission
> because I trust your script, this is the heart of the problem and this is
> wrong.

So you need to grant local {user?|admin?} the permission to sign
executables?

> 
> 
> > >
> > > How did Vista "solve" this problem?
> > > When the a software prompts for extra permissions, the user see which
> > > software asked for that, and if it's digitally the application's name and
> > > author are displayed.
> > > The user is expected to examine those details and allow the program to
> > get
> > > extra privileges if he wishes (software from sun? OK it's a java update,
> > I
> > > clicked on Firefox installer I expect software from Mozilla Foundation to
> > > prompt for permissions, unsigned software is asking for permissions after
> > I
> > > clicked to update my Java - wow, that's alarming!).
> > > Of course there are many problems with this approach (for instance let's
> > > sign my malware for "the Sun Inc" instead of "Sun Inc"), but it's a good
> > > first step.
> >
> > A certificate may serve to guarantee that the software indeed comes from
> > a well-known vendor. But it says nothing about it being safe for running
> > under sudo.
> >
> > Do I want to allow my users to run all the Sun programs? (and by
> > extension: all Java programs, through a JVM) with root privs?
> >
> 
> Hold it a bit, most software won't need to run as root, so usually the
> answer is no. It is legitimate to require scripts that are supposed to run
> as root to be compiled to a signed executable that would be signed. (It is a
> good idea in general BTW, for instance gnome-do fails to recognize java
> programs which are ran by bash script).
> 
> BTW you don't have to sign the executables by crypto. It is enough to show
> the full path of the software, and warn the user if he has write permission
> to the place where the executable resides.

So now we don't assume user is completely clueless, and we basically
drop the whole signing idea.

Full command-line sounds saner. gksudo alsready does that here.

> 
> But even for scripts it improves the system security. Since you would see
> exactly which command line is about to run, and you would be able to decide
> if you are being tricked or not. (It is much more unlikely that a malicious
> software will follow your keystroke an would switch the script you're just
> about to sudo).
> 
> The bottom line is, that I feel 100% safe to click OK on my Java update sudo
> in Vista, but I feel scared to do the same for the update manager on Ubuntu.

> 
> While its not the ideal solution, I believe it gives a good MAANE

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