Security problems with sudo

[Oswald Buddenhagen]

On Sun, May 17, 2009 at 01:39:31PM +0300, John Tapsell wrote:
>   The problem is if you ever run sudo (or graphical equivalent) as a
> normal user then its trivial for another program to exploit that and
> silently become root.  There are dozens of ways to do this, but
> ultimately the problem is simply that you need to elevate prillages in
> an untrusted environment.
> 
>   Now the question is..  is there any way to protected against this?
>
the fundamental problem here is the lack of compartmentization within a
user session. this also has the effect that a compromised IM client can
0wn the entire account of the user, and consequently the entire system
by exploiting the above sudo problem.
you can solve it only by putting each "task group" into an own context
(sandbox). this goes into the direction of personal firewalls. openbsd
has systrace for that. linux has SELinux and AppArmor, but these are not
desktop-deployable because they have no interactive mode (which again
brings new challenges regarding X security - dunno whether these were
solved meanwhile (think XACE - somebody cares to research?)).

> The best that I can think of is having a special shortcut that only
> the kernel can see (like ctrl+alt+del in windows)
>
that's called a secure access key (SAK).
but this secures only the explicit activation path, i.e. protects
against trojans popping up fake windows (provided the user actually
mistrusts unsolicited password prompts).
things become more complicated when privilege elevation is needed
implicitly, e.g., the entire PolicyKit story. how can the system
authenticate itself to the user? each opened dialog would have to be
confirmed by the SAK.

> then have the kernel draw a text prompt directly on the framebuffer
> etc.
>
slight overkill. the x server already runs as a separate user (always
root on linux) and protects itself fairly well (dri with some utterly
badly designed graphics cards breaks that, though).