[1137] in linux-security and linux-alert archive
Re: [linux-security] pty's and utmp - a disaster perpetrated long ago
daemon@ATHENA.MIT.EDU (David Holland)
Fri Sep 6 03:37:55 1996
From: David Holland <dholland@hcs.HARVARD.EDU>
To: miquels@cistron.nl (Miquel van Smoorenburg)
Date: Wed, 4 Sep 1996 13:35:33 -0400 (EDT)
Cc: ian@chiark.chu.cam.ac.uk, linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199609022133.XAA29765@picard.cistron.nl> from "Miquel van Smoorenburg" at Sep 2, 96 11:33:35 pm
> You (Ian Jackson) wrote:
> > We need
> > (a) a clear idea of how we want utmp to work
> > and
> > (b) a setuid root helper program which manipulates utmp and allocates
> > and deallocates pty's, and a library to call it easily.
A daemon is probably a better bet than a setuid root subprogram. Of
course, communicating reliably with an arbitrary daemon is a trifle
difficult.
I've done the survey of utmp-using programs. They mostly do one of the
following things:
- update an entry
- report all entries or all entries belonging to a particular user
- locate a user's least idle entry for messaging purposes
An interface that permits these things easily would be nice. Nicer
still would be to fix those tty-writing programs so they don't assume
the tty is the place to write; for instance, a utmp entry for an X
display should point messages to a named pipe or something.
Also, the utmp file as it presently exists should be abolished.
> You would need a special library call that calls a setuid helper
> program to allocate a pty, that gets chowned to the user. Or even
> better, the kernel could be fixed so that when you open the master
> side of a pty the slave gets chown()ed to the euid of the process
> opening it. In fact I think that would be very elegant, and I don't
> think it will break existing programs.
probably ruid, not euid -- existing setuid root tty management
programs would break.
Other than that, yeah, except that I don't think you can automatically
do it since the kernel doesn't know where to find the inode for the
tty end of the device.
What I've been thinking about is an ioctl on the pty end that takes a
file descriptor opened on the tty end as an argument and does the
necessary processing (chown, chmod 600, revoke). So you'd do something
like
while (1) {
char *x = mumble_get_next_pty_name();
if (!x) break;
p = open(x, O_RDWR);
if (p<0) continue;
x[5] = 't';
t = open(x, O_RDWR);
if (t<0) { close(p); continue; }
if (ioctl(p, TIOCCHOWN, &t)<0) continue; }
close(p);
t = open(x, O_RDWR);
if (t<0) continue;
return t;
}
return -1;
Note the reopening of the tty end - I suspect the ioctl should close
the descriptor passed to it, since it will be easier to implement the
revoke() part that way.
The other thing is, I don't think it's safe to trust the controlling
tty of a process to belong to that process's owning uid. If somebody
leaves a tty world-accessible for some reason, it's very easy to make
that tty your controlling tty. If you can steal utmp entries (or
worse, get the tty chowned) you can make a good deal of trouble.
--
- David A. Holland | Number of words in the English language that
dholland@hcs.harvard.edu | exist because of typos or misreadings: 381
