>> login procedures should begin by pressing this combo. However I
>> was told that this is "an NT way" solution, but I disagree.
It is called "Trusted Path", part of B1-level security.
> this is NTish. a keyboard combination would only appear to protect
> console access. there are a variety of ways to log in from the console.
It actually does protect you.
> if a trojan program can run, it can act on the the hotkey just
> completely as xdm or other login program.
No way. When you press the secure login keys, all processes on
the console die, die, die!!! You don't have to worry about raw
keyboard mode either, because this is flaming DEATH!!! from the
kernel itself. After that, init can start a nice clean login.
To make sure everybody uses the sequence, the login prompt should
time out. After that, it refuses login so that you must press the
special keys.
>> event and give a system menu or something similar. (xdm logins
>> can also begin with pressing the magic keys). I think the hard
>> part is about the
>
> this is a userland issue.
No way. That would be insecure.
>> fact that unices have got deeply integrated network layer so it's hard
>> to figure out the differences between local and remote logins on virtual
>> terminals, X servers etc, and do the CORRECT and SECURE method without
>
> quite so.....your X server is talking via network connections.
No, X talks via raw keyboard access on the Linux console.
You must use the framebuffer device X server, so that you can
kill the X server with the special key sequence. Die X, DIE!!!
>> Login can't accept ANY character before you don't press the combo.
>
> i hack pop3, ssh, ftpd, etc. i gain root. i replace /bin/login.
> *blam* it looks like a cherry, it tastes like a cherry, it's red...
> is it a cherry?
You don't gain root. (if you did, who cares anymore?) This is about
normal users writing fake logins that might get root's password.
>> kernel-user model. Security must give a way to have a trusted method
>> for user to check if it's not a trojan thing. This way now is the combo
>
> this really isn't possible. a user isn't necessarily going to *know*
> what the admin has installed.
The admin installs a kernel that supports Trusted Path, and the user
is told that they must always press the special key sequence. The admin
might even leave a login prompt waiting to catch and disable any luser
that is stupid enough to trust the login.
>> which cannot be unmasked by a regular user. As we see, it's needed to
>> hook the report of the combo - eg by login - but this hooking only be
>
> a regular user can't install a /bin/login (which is called by the getty)
> unless he's already gained privileged access.
They can't, BUT THEY CAN FAKE IT. It is very easy to write someting
that looks like a login, and just leave it running from your account.
Instead of logging out, do "exec my_trojan_login".
>> allowed by trusted programs : root processes or even something like
>> that already presents in Linux privs patch ?). This policy with including
>> the already-known kernel menu would get the whole system simplier
>
> erm... the kernel doesn't do menus :)
No, but it could. Perhaps it ought to.
> i do think that most of your logins come from socket based connections,
> not from the console.
Clients need the same protection, or must have physically protected
consoles. (in all cases the computer innards must be protected, but
many people want to allow multiple access to the keyboard & video)
> this is kind of like putting fancy wood around a window.
> it's fairly easily subverted by anyone who has privileged access.
The filesystem permissions are too... shall we all use vfat?
> being that this is unix, and not single user based. such a hotkey
> combination is fairly invalidated. the reasoning behind this is twofold.
> multiple means of console access are provided, some are "directly
> connected" to the console, and others are thru various login programs such
> as xdm and screen savers.
The X server itself gets flaming DEATH!!! It can not resist the kernel.
The clients never had direct control over the console, so they don't
really matter. You get a new (Trusted, safe, non-trojan) xdm from init.
> the second reason, the login program is a userland program, and called
> by another userland program. the kernel doesn't care diddly squat
> about the login process. it has no concern and does nothing in the
> process. therefore, anything can run in the place of your hotkey combo.
No, the kernel manages the console and all processes. In response to
special key sequences on the console, it can kill all processes that
have access to the console. After that, init starts up a new getty.
-
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.tux.org/lkml/