Enterprise secure dapper? sudo concerns/proposal

[Tristan Wibberley]

Eric Feliksik wrote:
> After the thread 'cross-platform virus' that featured wild speculation,
> curiosity, and thoughtful comments, I have some sort of summary and a
> few proposals/options. I launch it here on sounder; if a
> canonical-developer thinks this is a thoughtful mail I can make a
> wiki-page and/or the discussion might be moved to -devel.
> 
> THE ISSUE:
> The use of sudo in it's current setup practically means that if the
> first user account is compromised, root priviledges can be gained [1].
> We have not seen any undertakings to really fix this issue in the short
> term.

[snip]

> PROPOSALS:
> These are some creative thoughts, some might be more wise than others. I
> know plans like plash[2] (to reduce the amount of code ran as root) are
> on their way, but this might be useful anyway. (I suggest maintaining
> the capitalised issue names for convenience/recognition-reasons):

plash is good as a prototype, but, having read about it briefly, its
functionality should be moved into the kernel to catch all programs, not
just well behaved, dynamically linked ones.

> 1) SUDO UNTRUSTED-OWNER WARNING
> All programs owned by root already got in somehow; they're trusted.
> gksu can safely run root-owned programs (provided the password is given,
> of course). For user-owned programs, however, a different "enter your
> password" dialog must be displayed. Joe Sixpack will probably never see
> this, unless someone is trying to mess with his system. (Because Joe
> only uses software installed via apt-get, he does not care to run weird
> user-owned scripts with sudo). Dialog contains a red alert ("trying to
> run an UNTRUSTED program!"), and the full program path for
> identification purposes. (the gdebi warning should match this somehow,
> because it's about the same risk. I personally think the gdebi warning
> could use some bolder text)

It is not enough to check that sudo is being asked to run a trusted
binary, since trusted binaries can be asked to run other programs, and
it is pretty easy to do this by mistake too. Rather sudo should be
configured with a whitelist instead of the current "sure, run anything".

> 2) GKSUDO-SPOOFING
> Skip this issue if you have little time: this involves wild speculation
> for a solution. The problem here is basically the previous one inversed;
> You know when sudo will run a potentially malicious program, but how do
> you know a program doesn't run a malicous gksudo-faker? Malware can
> pretend to be gksudo and sniff your password (as far as I know, I don't
> know the details of this). I don't know a good solution to fix this, but
> I'll be creative:
> We might let X identify the real gksudo in some distincting way. Two
> pretty ugly options:

This can be done with a UNIX domain socket. The trusted process can send
its euid over, and even an fd to a pty for user input to be sent over
directly to the trusted process. If you pass a SysRq keystroke through
to the X server it could enter/exit protected mode on command to allow
the user to use accessibility features of the GUI. This way, sudo in a
terminal can also be handled.

> - It's probably possible to prevent user-owned programs from modifying
> the whole X screen, like gksudo does. (root-owned programs ran with
> user-priviledges, like gksu, *can* modify it, then). Problems are that
> this would break your user-installed tuxracer, and that it probably
> requires some heavier xorg modifications.
> - implement the previous option but only for a small section of the
> screen, like a 4 pixel border. Users should only enter their
> gksudo-password if the border of the screen is red, something like that.

Yeah, this is the difficult bit. It is also difficult to handle for the
visually impaired as it is hard to devise a sound that you can prevent
from being spoofed in legitimate applications.

Perhaps you can allow users to guarantee they are typing into a secure
channel by pressing a particular SysRq combination and waiting for
confirmation. So change sudo and gksudo to connect to the X server's (or
getty's) UNIX domain socket and request a secure channel. When the X
server gives them one, they can give the user the message to press the
secure channel keystroke whereby the X server ensures nothing is spoofed
or sniffed. The gksudo dialogue can even be moved out of gksudo into the
X server and use the same dialogue for both sudo and gksudo (and su).
Let programs queue up for the secure channel.

The problem of using sudo on another machine over, say, ssh remains to
be solved. Are programs with different euid and uid sniffable/modifiable
by either user? If not, you could make ssh run as a dedicated ssh user
via suid and it would remain unsniffable, and be able to be trusted so
it could negotiate like the X server on the other end and negotiate like
sudo on this end. Are there any problems with that approach? I expect
so, I only just thought of it.

> 3) BAN 'sudo -s'
> 'sudo -s' is pretty dangerous, as it runs .bashrc of the user with root
> priviledges. 'sudo -i' should be used instead. I know it's nice to see
> the $PS1-settings when logged in as root, but that can be achieved in
> another way, too. I'm still using 'sudo -s', but trying to unlearn it. A
> A warning in the manpage is in place, but then still "alias sudo='sudo
> -s'" is pretty freaky. Maybe the functionality is best taken out (or, at
> least, a warning upon using -s option).
> 
> That's all for now, folks! I'm sure if forgot some leaks, but I think
> this might improve security anyway. Thanks for your time.

4) configure whitelists of things that can be run with sudo, with
argument matching too, instead of allowing everything by default. Let
the administration packages like synaptic add themselves. Let them
provide default rules for how to do this, and let administrators add
rules for transforming machine and user names for their own setups.

5) make kernel log root exec's (that shouldn't be happening much anyway)

6) make kernel log every time a suid or sgid program is started

-- 
Tristan Wibberley