Re Kubuntu 64bit, several issues

Tristan Wibberley maihem at maihem.org
Mon Aug 15 16:21:55 CDT 2005


Daniel Stone wrote:
> On Mon, Aug 15, 2005 at 08:31:21PM +0100, Tristan Wibberley wrote:
> 
>>Daniel Stone wrote:

>>>Similarly, there is no way to know that 'su' is not trojaned.  There is
>>>no way to know that there's not a hardware keylogger embedded in your
>>>keyboard, because I assume that you have not considered physical
>>>security.
>>
>>I think this is a bit fatalist. At the risk of being rude, but with the
>>intention of being clear, I'd like to paraphrase: "It is impossible to
>>be one hundred percent secure, so don't even bother trying to stop the
>>easy cases of zlib exploit leading to high probability of keylogging
>>capability".
> 
> 
> The lesson I would take home from that quote would be more towards
> auditing zlib if everything depended on it, rather than attempting to
> fundamentally redesign the way computers work, which is something not
> even the SELinux people, backed by the NSA, have managed to properly and
> securely achieve after years of work so far.  Oh well.

I'm not fresh off the CompSci boat, I am proposing nothing like
fundamentally redesigning the way computers work. I'm also proposing
nothing like the scale of what SELinux is doing (which requires a large
number of hooks throughout the kernel). I am proposing using regular IPC
permissions, IPC, privileged processes, and significant but (I suspect)
mostly straightforward alterations to a number of userspace programs. In
particular, sudo, su, gksu, xserver-xorg, and possibly terminal
emulators - but I suspect the latter is not necessary, since the user
experience of running sudo from a terminal could just change to run gksu
when sudo finds it is being run in an X Windows environment.

That leaves remote terminals to sort out. And I'm going to carry on
thinking about them until I'm satisfied.

[...]

>>At which point you have to do something both difficult to do, and
>>difficult to not get caught doing. Using the desirable sudo mode of
>>administration makes the system script-kiddie-fodder...
> 
> 
> It's not that easy to do.  Windows are easily prised open, and if I do
> it while everyone's at work, then no-one's likely to notice.
> 
> Point is, your physical security is likely to be easier to compromise
> than your computer security.


Possibly for a hired expert, but the cost of the effort per compromise
in fleshland is huge compared to that in cyberworld. So individually
targeted attacks remain difficult to stop, but there is a whole lot of
harm caused by indiscriminate phishing attacks.


>>Script kiddie puts standard exploit script on web page, Dad visits
>>website with unpatched firefox, son phones dad to tell him a new firefox
>>is available and to patch his firefox, dad goes to synaptic to upgrade
>>it, enters his password and *bang*. This could also happen with
>>thunderbird, and as Linux and thunderbird become more popular, that sort
>>of active attack will happen with more frequency just as it does on Windows.
> 
> 
> At that point, you have lost, sure.
> 
> But I do not see how this thread has proposed an alternative to this.
> How do you propose to securely authenticate these processes?

A root (or some dedicated security user) writeable socket.

> Look for a file you know only root can create?
> Bad news, I've just wrapped open() and stat(), et al.

Not when the process doing the checking is running as root.

> Check that the process is running as root?
> Bad news, I just faked that out too.

When the process doing the checking is running as root, you cannot fake
that out.

[...]

>>See above for an alternative to trusting every gui terminal emulator.
> 
> 
> No, that doesn't hold water.
> 
> Let's say sudo has some method (writing to a file in /etc/securitywow)
> that is only available to root processes, of informing gnome-terminal
> that it's doing secure things and could gnome-terminal please do secure
> things now too.
> 
> Let's say I write a very small wrapper around gnome-terminal, or just
> modify it in-memory when it's running, that disables this bit of code,
> which I'm perfectly within my rights to do as the user that's
> attempting to run this bit of code.

So combining writing to a file that is only available to root processes
with having gnome-terminal watch for that write won't work. True.

>>Yes, but I'm proposing that the *real* programs for escalating your
>>privileges actively do something to ensure that the route of data from
>>PS2 port to themselves is secure, with the cooperation (as necessary) of
>>input driver, X server, etc. Then do something with the cooperation of
>>terminal emulator (with possible privileged component) and X server to
>>show you that it is secure that can't and/or won't be done if a
>>non-privileged process is involved.
> 
> 
> It's the 'something', which is being completely handwaved over, that is
> the most important -- and virtually impossible to implement -- component
> of this.
> 
> The paragraph here is very good: I can't disagree with it in any way,
> shape or form.  What I'm suggesting is that the complete lack of any
> concrete ideas from anyone about what 'something' might possibly be, is
> because it's a stupendously difficult problem to solve, and that no-one
> has managed to solve it yet is a reflection of the depth of the problem
> space, rather than it being unpopular.

You gave the something above. Write to a file that is only available to
root processes. When gnome-terminal watches for such a write, it is
worthless, because gnome-terminal is running with my uid, but the X
server, on the other hand, is not. Combine writing to a magic file (or
better, a socket) possibly with a daemon that notifies relevant
listeners (authenticated in a similar fashion) that they should present
a secure environment for entering a password and bill it as secure in a
way that they do not allow to be done by normal X clients in the users
session (eg, the password window *will* be on top, and no two ways, etc
- this is specific to the software controlling the console).

I have deleted a few things, as I believe they have been answered whilst
answering other points.

BTW, Thanks for forcing me to think more concretely, I do get a bit
handwavy at times.

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.




More information about the ubuntu-devel mailing list