Re: Solaris 2.x utmp hole

[scott () Disclosure COM (Scott Barman)]

To all who have responded directly to me regarding this topic, I
apologize for not returning your email.  I wanted to verify a few
things first, before commenting.  Now, I am fairly certain that what I
found is correct:

After playing with the sample program, I RTFM.  Actually, I RTFM before
this to see what the *utxline() functions did.  This time, I actually
read every word!  In the man page for getutxent(3C) I found:

     file.  It returns a pointer to the  utmpx  structure.   When
     called  by  a non-root user, pututxline() invokes a setuid()
     root program to verify and write the entry, since /etc/utmpx
     is  normally  writable  only  by  root.   In this event, the
     ut_name field must correspond to the actual user name  asso-
     ciated  with  the  process; the ut_type field must be either
     USER_PROCESS or DEAD_PROCESS; and the ut_line field must  be
     a device special file and be writable by the user.

Which program?  On my box, it seems to be a pretty good secret.  But
being curious, I had to find out!  I dynamically loaded the binary to
see if running strings(1) on it would tell me.  No luck.  Then I used
abort(3C) after the pututxline call to find a file name.  That worked!
It seems that when a user tries to do the update, the following
program is run:

-r-sr-xr-x   1 root     bin         5996 Jul 16  1994 /usr/lib/utmp_update

This is from a Solaris 2.4 on a pee cee.  On my system, utmp_update
will only allow me (the user) to update the ut_type field.   It
wouldn't let me update the ut_line field.  I even put in "real" line
names (look at your /dev directory and the 1001 symbolic links, Sun
seems to have gone bananas with symbolic links again!).

I called a friend at Sun in Mt. View.  He confirmed this for me and that
it is not a bug, but a feature!!  :-)  Then I asked some questions.  I
am going to paraphrase my questions and his answers (he asked to remain
anonymous)--mainly because I don't take short-hand!  I believe they are
fairly accurate.

Key: Me:  Scott Barman (me!)
     SE:  My friend the software engineer at Sun.

Me: Why is this a "feature?"
SE: For all the 1001 things that init now does, it doesn't "log out" a
user when the user hangs up.  The shells have all been hacked to catch
all the signals and if they are going to exit, to update the utmp and
utmpx files before they go.  The init under SunOS did write logout
messages to utmp when the process attached to the tty exited.

Me: Is it possible for a user to make it look like he/she was not logged in?
SE: No.  Not unless someone hacked init.  It generates a login message
for all connections, including ftp.  Actually, it's login and ftpd that
make those entries, not init.

Me: What about security?  Isn't this dangerous not knowing who is on the
system?
SE: Do you enforce the use of the "-ls" option with xterm?  (The -ls
starts a login shell to the window) Or do you run shelltool and
command tool?  How easy is it to run an rsh to start an xterm to get
displayed on another system?  I do it all the time, and my "login"
information does not appear in the wtmp file.  If these do not create
umtp entries to begin with and you run them, why should this be a
problem?

Me: The way the manual reads I can change the ut_line field but my
test program cannot.  Why?
SE: The man page says that?  The man page is wrong!  The wtmp_update
program uses the user name and the line value to find the proper
record for the user.  If you do not pass the correct values, the
wtmp_udate program will not do the update. 

Me: Is there anyway to make it look like someone is still logged in when
they are not?
SE: Haven't you seen this on SunOS?  Xterms do this all the time!!  (I
have and they do)  I don't think this is a security problem.

Me: Some people have suggested this is a security hole.  What do you say?
SE: It's more of a pain in the behind than anything else.  We've had
customers call up and complain because they were relying on init to
record the "logout" of their custom app, one that is started like a
login shell (after login runs).  But that's System V.  We have to be
SV compliant, so we do what the specs say and this is how the sources
came to us.

The rest of the conversation was "personal" in nature (he's an old
friend!:-).  However, he did convince me it wasn't as bad as it looks
and is really not something to worry about.

Then again he and I also agreed that the System V init was too bloated,
did too much and we both couldn't find that much of an advantage in it
over the old init in SunOS.

I hope that answers the questions on this subject.

scott barman
scott () disclosure com

DISCLAIMER: I speak to anyone who will listen to me and I speak only for myself!