On 14/06/2010 19:12, Elazar Leibovich wrote:
The problem:
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.
We *want *those application to constantly run in the background and
prompt the user to take action. This is a good thing.
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.
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.
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.
This program can be solved in many ways, for instance:
1) Allow the user to sudo only a limited set of software.
2) Allow the user to sudo all programs, but do not allow any software to
prompt the user for extra permission.
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.
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.
On Mon, Jun 14, 2010 at 6:55 PM, Tzafrir Cohen <tzaf...@cohens.org.il
<mailto:tzaf...@cohens.org.il>> wrote:
On Mon, Jun 14, 2010 at 06:16:11PM +0300, Elazar Leibovich wrote:
> On Mon, Jun 14, 2010 at 6:04 PM, Tzafrir Cohen
<tzaf...@cohens.org.il <mailto:tzaf...@cohens.org.il>>wrote:
>
> > On Mon, Jun 14, 2010 at 05:47:36PM +0300, Elazar Leibovich wrote:
> >
> > > Again, sudo is super.
> >
> > Surely it's not. Super is a sudo replacement.
> > http://packages.debian.org/super
>
>
> It is hard to find an adjective which is not a debian package yet ;-)
>
>
> >
> >
> > > I even considered a using it on some windows machine
> > > which unfortunately lack this feature. It's the Ubuntu GUI
for leveraging
> > > permisions which bothers me.
> > > I took a quick look of the *Kit stuff. I don't see
immediately what
> > > ConsoleKit is doing, but indeed disabling any possibility to
sudo through
> > > the GUI, and only running a package daemon is a nice step
towards a
> > better
> > > authentication scheme.
> > > However I don't see how is it a solution for the general
problem of
> > > executing untrusted binaries in Desktop environment.
> >
> > It's not. Nither is sudo. It's intended to help you solve the
problem of
> > a giving a semi-trusted user partial sysadmin permissions.
Different
> > problem.
> >
>
> sudo doesn't solve the problem, however it might help with
solving it. For
> instance Ubuntu uses GUI wrapper for sudo in order to try and
solve the
> problem.
> And indeed we're talking about different problems.
> Usually for the personal computer the user is totally trusted,
but the
> software he's installing is not always trusted. We wish to make
sure that
> administrative actions are initiated by the user, and not by a
software he's
> running. I've yet to hear a different solution than the Vista one.
I really fail to understand you. Could you please state the exact
problem you believe needs solving and how it is solved?
--
Tzafrir Cohen | tzaf...@jabber.org
<mailto:tzaf...@jabber.org> | VIM is
http://tzafrir.org.il | | a Mutt's
tzaf...@cohens.org.il <mailto:tzaf...@cohens.org.il> |
| best
tzaf...@debian.org <mailto:tzaf...@debian.org> |
| friend
E.G. Run rkhunter as a startup procedure or wrap sudo in a script
that checks
--
Moish
_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
