Linux login security approaches

Lenart Gabor (lgb@hal2000.hal.vein.hu)
Mon, 7 Dec 1998 14:41:43 +0100


Beginning with a nice story ...

Some hours ago we had a discuss on Linux security, here at the University.
I mentioned that Linux has got a weak point : every user can write a fake
login program and even the system administrator can think that it's mgetty
and type the root password :( This kind of Trojan programs can be preceded.
We should define a key combination which is unmaskable by ANY process, and
login procedures should begin by pressing this combo. However I was told that
this is "an NT way" solution, but I disagree. (I don't know anything on
NT before I've hopefully never used it :) But the idea is great. The fact
that this combo is unmaskable is not quiet right because eg using X
it would be nice to allow for X server to "bind" this important keyboard
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
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
giving ANY chance to creakers to write something trojan program by
confusing the user with a fake login screen. (And what about other
situations when eg. ssh ask for your password ? Logically it's true that
your terminal is trusted when you've already logined into the LOCAL
machine with starting the keycombo. If we assume that other servers
are secure enough too, now it's secure to accessing them through the
network IF network is secure enough as well. I think firstly it would
be enough to think about the security concept of local logins "only")

Login can't accept ANY character before you don't press the combo.
After pressing it we should setup a timeout.
When the actual terminal is active (I mean it's not a login screen),
pressing this combo should casue something of menu which allow us to
logout and even other well known kernel menu options present
(Now it's clear that a secure system mustn't work with sharply seperated
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
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
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
and more elegant in my oppinion (but we should give a method to avoid
using kernel-menu functions for everyone who has access to the console.
In a perfect world consoles and even servers cannot have physical access
for untrusted people ... But it's now always true. The trojan login
screens I'm talking about cannot be implemented with a secure console
and in this case my letter is absolote with the unsecure kernel-menu
using as well :-)

And now the problem is solved : you press the combo to allow you to begin
type your login name & password. If the login screen was the result of
an evil hacker, the combo will casue a menu instead of the login prompt,
so you're not confused. Am I right ?

It's only a theory. Unfortunetly I don't know enough about Linux
(as you can already seen by reading one of my mails sent to the list),
so be patient with my probably stupid ideas, please :) I hope you
CAN understand my poor English.

bye : Gábor Lénárt,

---[ LGB/DC ]------------------[ root@hal2000 ]-----------------[ LINUX ]---
"The truth is out there" "We're living together" "The future is dark."
---[ 88/422022-4602 ]--[ http://www.hal.vein.hu/~lgb ]------[ 87/477074 ]---

-
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/