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.
> 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
if a trojan program can run, it can act on the the hotkey just completely as
xdm or other login program.
> 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.
> 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. if you
want to get picky about it, /bin/login is talking via `connections'. i.e.
tty pairs. /bin/login is called from a variety of sources, both console
and network.
> giving ANY chance to creakers to write something trojan program by
> confusing the user with a fake login screen. (And what about other
unfortunately, this is likened to sticking your head into the sand and
pretending you're secure :)
> 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
no. logically you trust the connection in a measurable amount. even ssh
has shown fatal flaws.
> 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")
nope nope.
> 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?
> 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.
> 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.
> 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 :)
> 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 :-)
i do think that most of your logins come from socket based connections,
not from the console. this is kind of like putting fancy wood around a
window. it's fairly easily subverted by anyone who has privileged access.
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 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.
the quest for ultra security is a good one. unfortunately, it is
inversely proportional to the complexity and work required by developers,
and the load placed on a system.
-d
-- Look, Windows 98 Buy, lemmings, buy! MCSE, Must Consult Someone Experienced __ (c) 1998 David Ford. Redistribution via the Microsoft Network is prohibited \/ for linux-kernel: please read linux/Documentation/* before posting problems
- 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/