shadow chown(tty) - problem

Richard Lightman richard at nezumi.plus.com
Sun Sep 1 08:02:07 PDT 2002


* Bill Maltby LFS Related <lfsbill at wlmcs.com> [2002-09-01 15:00]:
> On Sun, 1 Sep 2002, Richard Lightman wrote:
> 
> Security question? Has the spy process acquired the user login and
> password before conlogin kills it?
> 
Not if you take some simple precautions:
------------------------------------------------------Captured by spy:
[root at urusai tmp]# nohup /var/tmp/spy /dev/vcc/3 /dev/vcc/2 &
[1] 3558
[root at urusai tmp]# nohup: appending output to `nohup.out'
nohup /var/tmp/spy /dev/vcc/a3 /dev/vcc/a2 &
[2] 3561
[root at urusai tmp]# nohup: appending output to `nohup.out'
exit
logout

urusai.localnet.rcl login: SysRq : SAK

urusai.localnet.rcl login: richard
Password:
Last login: Sun Sep  1 15:15:02 +0100 2002 on vc/3.
You have new mail.
------------------------------------------------------Spy missed this:
killed process 3558
killed process 3561
Controlling terminal is /dev/vc/3
Today is Prickle-Prickle, the 25th day of Bureaucracy YOLD 3168. Wibble.
[richard at urusai richard]$
-----------------------------------------------------------------------

That "SysRq : SAK" is there because I typed <alt><sysrq>k. This kills
the process reading terminal. This had no effect on spy. Init restarted
agetty, so now I could be sure that this is an honest agetty, not some
fake after may password. To enable secure acknowledge (SAK) you
must enable the magic sysrq key in the kernel. The bad news is this
also enables some vicious debugging features that you may not want to
give to whoever is sitting at the console.

Next, I waited for my hard disk to spin down before typing my name,
and then I typed my password immediately. Unfortunately, login was
still cached so there was no delay starting login, and none of my
password was captured. Spying on /dev/vcc/* only picks up things
that you can see. You can avoid the problem by waiting for the
"Password:" prompt.

Spy did find my last login date, and that I have mail. After that
conlogin starts. Conlogin changes the owner before killing processes,
so new processes owned by other users can use the device. If there
were two spies looking out for the other, then one could fork when
the other dies, and AFAIK conlogin would not spot the new process.
This spying technique would be difficult, and I suspect unreliable.
If you are worried, you could run conlogin twenty times in the
background and be reasonably sure nothing nasty would survive.

Conlogin reports the kill after sending the signal. Perhaps (on
SMP machines) spy could capture a little more while the signal
is being delivered. My prompt took a small amount of time to
appear because my .bash_profile was checking some other virtual
terminals, and starting shells on ones where I did not have a shell.
By the time my prompt has appeared I can be reasonably confident
that the spies are thorough dead.


I am more concerned about conlogin being a security risk. I wanted
/dev/scsi/host0/bus0/target0/lun0/generic to be owned by the person
on the console so he can burn CD's. Unfortunately, this gives away
a dangerous amount of power. There were probably other devices that
should not be in cologin's config file, and now that conlogin kills
things, there are probably more. Anyone know some examples?

Richard



-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list