<div dir="ltr">The problem:<br>In the current workflow for desktop linux, you need to routinely leverage the privilege of some GUI application. Those applications runs constantly in the background and might prompt the user to take action.<br>
We <b>want </b>those application to constantly run in the background and prompt the user to take action. This is a good thing.<br>When the program asks the user to leverage its privileges, the standard leverage dialog does not contain any verifiable information for who actually asked to leverage its permissions.<br>
That is, the only authentication method the user employ to verify he's giving root privilege to the correct program are this program's visual look.<br><br>However, this workflow enables a simple attack. The offending program would change its look to look like a legitimate program, and ask the user to leverage its permissions. The user has no way to know that he's leveraging the permissions of a different program.<br>
<br>This program can be solved in many ways, for instance:<br>1) Allow the user to sudo only a limited set of software.<br>2) Allow the user to sudo all programs, but do not allow any software to prompt the user for extra permission.<br>
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.<br>
<br>How did Vista "solve" this problem?<br>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.<br>
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!).<br>
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.<br><br><div class="gmail_quote">On Mon, Jun 14, 2010 at 6:55 PM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir@cohens.org.il">tzafrir@cohens.org.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">On Mon, Jun 14, 2010 at 06:16:11PM +0300, Elazar Leibovich wrote:<br>
> On Mon, Jun 14, 2010 at 6:04 PM, Tzafrir Cohen <<a href="mailto:tzafrir@cohens.org.il">tzafrir@cohens.org.il</a>>wrote:<br>
><br>
> > On Mon, Jun 14, 2010 at 05:47:36PM +0300, Elazar Leibovich wrote:<br>
> ><br>
> > > Again, sudo is super.<br>
> ><br>
> > Surely it's not. Super is a sudo replacement.<br>
> > <a href="http://packages.debian.org/super" target="_blank">http://packages.debian.org/super</a><br>
><br>
><br>
> It is hard to find an adjective which is not a debian package yet ;-)<br>
><br>
><br>
> ><br>
> ><br>
> > > I even considered a using it on some windows machine<br>
> > > which unfortunately lack this feature. It's the Ubuntu GUI for leveraging<br>
> > > permisions which bothers me.<br>
> > > I took a quick look of the *Kit stuff. I don't see immediately what<br>
> > > ConsoleKit is doing, but indeed disabling any possibility to sudo through<br>
> > > the GUI, and only running a package daemon is a nice step towards a<br>
> > better<br>
> > > authentication scheme.<br>
> > > However I don't see how is it a solution for the general problem of<br>
> > > executing untrusted binaries in Desktop environment.<br>
> ><br>
> > It's not. Nither is sudo. It's intended to help you solve the problem of<br>
> > a giving a semi-trusted user partial sysadmin permissions. Different<br>
> > problem.<br>
> ><br>
><br>
> sudo doesn't solve the problem, however it might help with solving it. For<br>
> instance Ubuntu uses GUI wrapper for sudo in order to try and solve the<br>
> problem.<br>
> And indeed we're talking about different problems.<br>
> Usually for the personal computer the user is totally trusted, but the<br>
> software he's installing is not always trusted. We wish to make sure that<br>
> administrative actions are initiated by the user, and not by a software he's<br>
> running. I've yet to hear a different solution than the Vista one.<br>
<br>
</div></div>I really fail to understand you. Could you please state the exact<br>
problem you believe needs solving and how it is solved?<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Tzafrir Cohen | <a href="mailto:tzafrir@jabber.org">tzafrir@jabber.org</a> | VIM is<br>
<a href="http://tzafrir.org.il" target="_blank">http://tzafrir.org.il</a> | | a Mutt's<br>
<a href="mailto:tzafrir@cohens.org.il">tzafrir@cohens.org.il</a> | | best<br>
<a href="mailto:tzafrir@debian.org">tzafrir@debian.org</a> | | friend<br>
<br>
_______________________________________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
</div></div></blockquote></div><br></div>