On Sat, Jan 03, 2015 at 07:31:19PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 03.01.2015 07:27, Jude Nelson wrote:
>
> >> I'd rather raise the question whether that's useful at all.
> >
> > There was an LWN article on this a while back [2]. The examples
> > provided there are as follows:
> > * If the login program could revoke() the tty device node before
> > prompting the password, this attack vector would be removed (assuming
> > the revoke() implementation didn't affect file descriptors in the
> > calling process).
>
> Sure. But shouldn't that potentially attacking process be killed in the
> first place ?
>
> Anyways, if we're talking about local tty, a user sitting on front of
> the console can't even be sure that he's talking to the real login
> program, if he sees some login prompt. Doing trojan attacks here is
> pretty trivial (in fact, that was one of my first easy hacks, back in
> school, I was using to take over our admin's account - what eventually
> lead to /me becoming offical admin ;-)). To prevent that kind of
> attacks, we would need an separate output channel (eg. some special
> screen region, etc) which is exclusive to the real login program and
> cant be touched by arbitrary user processes.

There's a simpler cure:

After receiving the user's login name, find his home directory, find
his ~/passwordprompt file, and copy its contents to his terminal as
the password prompt. He should own that file, and make sure that
it is readable only by root (except when he's updating or changing
it, of course). If his chosen password prompt diesn't appear, he
should be *very* suspicious.

-- hendrik