In some (I don't know where) security handbooks it's written that Login
procedures must be started with pressing a special key combination
which cannot be unmaskable by user programs. NT implement this (but
I mentioned that I hadn't known this before !) but this is a security
requirement based on standards and not a Microsux hack or something.
> > 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.
And if only with root uid can be bind this combo ?
> > 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.
yes.
> > 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.
Everything in the world may contain security holes. But we must reduce
the risk with using more secure tools than before.
> 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?
My letter was not about this fact. Every system have got many possible
security hole. If you gain root priv, you can do anything it's true.
But writing a fake login screen is much simplier than creacking a GOOD
and secure Linux server, I think.
> > 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.
correct. Knowledge about used softwares etc give some information to the
a creaker to find out what is the weakest point of the system.
But I'm NOT talking about allowing users to get this information. I'm
only talking about to check if it's not a trojan login by for example
pressing that combo (it's ONE solution)
> > 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.
I mean writing a FAKED login, eg /home/evil/login which dumps a Login-like
prompt to the screen confusing other users and trying to login by
typing their login names and passwords !
> > 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 :)
2.1.x HAS got kernel menu. I call them menus. Sorry, maybe it's not
a menu exactly :)
---[ 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/