Re Kubuntu 64bit, several issues

Daniel Stone daniel at fooishbar.org
Mon Aug 15 13:51:00 CDT 2005


On Mon, Aug 15, 2005 at 07:30:18PM +0100, Tristan Wibberley wrote:
> Daniel Stone wrote:
> > On Sun, Aug 14, 2005 at 11:55:49PM +0100, Tristan Wibberley wrote:
> >>However, my fear in that respect has been
> >>shown to be unfounded since, once you have run a real system sudo
> >>binary, the password cannot be snooped.
> > 
> > Assuming you have ultimate trust in your terminal emulator, the 70-odd
> > shared libraries it currently *directly* depends on, the 17 or so
> > client-side X libraries that would be involved, etc.
> 
> The key word here is currently. If I thought that Linux was currently
> secure enough, I wouldn't have raised the issue. By raising what I saw
> as a problem, I expected that I had indicated an intention to cause
> change, either directly by creating patches after getting advice from
> other people, or by persuading other people to help, or even to do it
> all, but if I can do it (and it doesn't come too close to, or overlap
> with, my employers business - and after I've checked with them anyway) I
> will certainly try. First I need to work out what is the nicest way of
> doing it.

Computing is not sufficiently advanced to achieve what you want to
achieve, being the ability to determine whether you are really you, and
whether you have good intent.

> > Oh, and did I mention that anyone running as your user has full access
> > to your X session?  They're listening on the wire for key events, and
> > watching for the word 'sudo'.
> 
> I understand that the X server currently will happily give all
> keystrokes to anything that can connect to your session, and I am trying
> to say that I would like a facility where it will refuse in some cases,
> as directed by a suitably trusted system binary.

Even that will not help you, as I explained earlier.

> > Whoops, suddenly anyone running under your UID has your password.
> 
> But only if a program running under my uid recieves my password, or a
> program running as root happily forwards it on.

Sure.

> >>Then I think you would need only the terminal emulators (or relevant
> >>parts thereof) and the X server to be privileged, running as a different
> >>user, or otherwise unsnoopable.
> > 
> > 'Otherwise unsnoopable' is a nice idea, but utterly technically
> > unfeasible.
> 
> For the third case perhaps infeasible (but not necessarily impossible),
> for the case of "running as a different user" certainly not, as that is
> normal operation.

This is a policing-the-police problem: how do you authenticate the
authenticator?  What's to say that the program running under your UID
that is responsible for launching sudo is secure?

> > As Matt said, you cannot protect yourself from yourself.  And once
> > someone has access to your account, you are entirely equivalent, as far
> > as the computer is concerned.
> 
> I do not believe we are. Because the attacker doesn't know my password
> before I type it, and if Linux can be given a way to tell me that I'm
> typing the password into a program that is not running as me and the
> keystrokes will only be passed on to such programs (ie the X server
> promises not to forward my keystrokes to any old thing), then the
> attacker will not get my password.

Unless he's modified bash in-process, and bash isn't forking sudo, but
~/bin/trojan-horse, or whatever.

> In that scenario, programs running
> under my uid do not enter the equation - they would only start the
> privileged process that sets up the secure environment for password
> entry. To get my password under that regime, the attacker would have to
> have root first - or a screwdriver and a crowbar.

'they would only start the privileged process that ...'

And that's where your argument falls down.  How do you know that it's
actually starting that privileged process, as opposed to some random
Trojan?

> The debate then, is how best to have Linux stop sudo from being a fairly
> straightforward target.

... not use it at all?

> However, if you don't wish to help me to work out the best way to do
> this, simply don't give me advice on it. I still firmly believe it *can*
> be done. I accept that a computer subject to natural laws cannot be 100%
> secure, but when a small bug in libpng or zlib can make it easy to
> stealthily install an effective trojan, something should be done to
> improve that use case.

You are welcome to attempt, and I certainly don't discourage you from
doing so if you feel that it's an effective use of your time, but I do
not believe that you are able to achieve what you want to while still
actually using a computer.



More information about the ubuntu-devel mailing list