lkml.org 
[lkml]   [1998]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kill -9 <pid of X>


On Wed, 12 Aug 1998, Alan Cox wrote:
>
> There was a real issue further down my email. How do you implement SAK correctly
> without kernel support for mode handling ?

By not allowing untrusted users to get access to the screen, perhaps?

In order to get into graphics mode in the first place, you have to have
root access. Which means that SAK is a complete non-issue, because if the
person who created a graphical trojan horse thing had root, he could have
done any number of things instead.

So you have two cases:
- graphics under X. You trust the X server, because if you didn't there
would be no point anyway - it could do whatever it wanted to you
because it has root. So you make a magic SAK keybinding for X, and when
X gets that it exits or re-spawns or whatever.
- graphics not under X.

For graphics not under X, I told people how to do this a long time ago,
and so far nothing has happened. Which makes me think that everybody who
complains about the issue either really doesn't care and just wants to be
a trouble-maker, or that they are incompetent.

When not under X, rather than having a SVGAlib library and compiling
everything to be suid root, you have a root wrapper executable, which is
suid, gets the screen changes modes, forks, gets rid of it's suid
privileges and does an exec(). You now have a normal user that has access
to the screen, but more importantly, you _also_ have a root wrapper you
trust. That root wrapper can handle SAK (the kernel knows who it is,
because it already had to register as a console switcher process).

(The root wrapper doesn't just go away: it stays in the background,
waiting for its child do die, or waiting for the kernel to ask it to
switch consoles).

Yes, there may be details that need to be done, but quite frankly, long
before any kernel issues even become involved, the thing has to be done
properly in user mode. Why are there still people who want to try to
change the kernel before they have even considered fixing SVGAlib etc?

Linux isn't a Windows NT where you add cruft in the kernel to get around
cruft in user programs.

In short, for me the issue is:
- I acknowledge that there may be kernel support lacking for some
operations. I wouldn't have any fundamental reasons to dismiss a kernel
module that X (or the SVGAlib wrapper) wants to load in order to run
safely.
- HOWEVER. As far as I'm concerned, before people start to whine to me
about kernel support, they'd better have their user land remotely ready
for it. The way I see it, the people who whine have not done
_anything_ to user land. As such, they are not people I feel I need to
talk to - they have shown themselves incapable of the thought "maybe I
should fix this in user land first before I complain to the kernel".

Short and sweet: get back to me on this issue when (a) X handles "kill -9"
properly (and yes, I agree completely with you that it should do
suid(0)+suid(xxx) rather than just suid(0)) and (b) SVGAlib doesn't
require that the whole application runs with root privileges.
Before that happens, I don't consider this a kernel issue.

Linus


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans