[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: trust [was Re: Open Xlock as root]

vorlon@netexpress.net writes:
>Well, because 'vlock -a' locks *all* the virtual consoles (and there's no
>magic key to break out of it--it wouldn't be a very good console lock if
>there was), the hammer the attacker would need to terminate the locked
>session would be one serious Hammer of Pok.  Specifically, the attacker
>would have to be able to reboot the machine.  So, if there's sufficient
>physical security in place, then vlock *is* resistant to such an attack.

vlock itself is resistant to an attack, but that doesn't mean that root
can trust something that looks like vlock.  vlock needs no special
permissions to do its work, so anyone who wants to can build and compile
a vlock that will take over the console and reap root passwords when root
comes along to try to unlock things.

That's one of the reasons that I've felt kind of queasy about including
root password unlocking in vlock; it occurred to me when I first wrote it,
and it's been uneasily in the back of my head ever since.  I feel like I
am participating in conditioning admins to give the root password out too
easily.  :-(

In order to be safe from this particular form of abuse, it is at least
necessary that untrusted users be unable to add the executable bit to
any file, or make the executable bit meaningless in areas that the user
can write.  That is most often done by mounting /home, /tmp, /var/tmp,
etc. with the noexec option.


"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz
 Linux Application Development     http://people.redhat.com/johnsonm/lad/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []