[11567] in bugtraq
Re: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock
daemon@ATHENA.MIT.EDU (Michael K. Johnson)
Sat Aug 28 20:57:44 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <199908251633.MAA01146@tristan.devel.redhat.com>
Date: Wed, 25 Aug 1999 12:33:57 -0400
Reply-To: johnsonm@REDHAT.COM
From: "Michael K. Johnson" <johnsonm@REDHAT.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Sun, 04 Jul 1999 13:38:48 +0200."
<lcamtuf.4.05.9907041223290.355-300000@nimue.ids.pl>
Michal Zalewski writes:
>--------
>vlock -a
>--------
>
>Compromise: locally, unlocking VCs switching under certain conditions
>
>When 'vlock -a' is called, console switching is completely disabled using
>ioctl() call on /dev/ttyX device. Under certain conditions, this
>protection can be fooled. Let's imagine following situation: user X is
>logged on tty6 - oh, abbandoned session ;) while root is playing on
>other consoles. After some time, he/she issued 'vlock -a' and gone
>somewhere. But, if user X is still logged on any console, and he's able to
>login once more, remotelly, he could open /dev/tty6 (in our example, as
>it's owned by him), then... use ioctl() (as it's not restricted to
>superusers!!!) to enable console switching.
This is not a bug in vlock; what's more, it's not a bug.
To change this behaviour in the way Michal wants would require that
all console-switching activity be controlled only by root. This would
have a detrimental effect on security, because it would increase the
number of setuid applications on the system. So this is not a kernel
bug, and since the behaviour Michal wants would have to be enforced in
the kernel and vlock is not capable of changing it, it is not a vlock
bug either.
michaelkjohnson
"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/
