[UCLA-LUG] gdm xdm question

[Patrick Oscar Boykin]

This is all very informative.

But now it make me wonder why xdm/gdm do not write to /var/log/wtmp when
someone logs in?

Could this be a bug or is this intentional?  I guess you could be logged
in with gdm, and not have a console window.  This may be the reason for it
I suppose huh?

Thanks

On Sat, 13 Nov 1999, Frederick Lee wrote:

> (Cue "Long-Winded Discussion Of Xterm, Wtmp, and Setuid"...)
> 
> The file for who's logged in or not is in the wtmp file, /var/log/wtmp
> or variations of it.  It's normally owned by root, and writeable only
> by root.  Otherwise, crackpots may fill it up with weird information
> and create "ghosts" on the machine.  Or worse, fill it up with garbage
> and cause programs that read it to choke and die (who, fingerd, etc.).
> 
> You'll notice that the default installed xterm has the setuid bit
> turned on (an "s" in the first column of "ls -l").  It's also owned
> by root.  As a result, xterm is a setuid root program.  When first
> started, it is endowed with full privileges of root, including changing
> the wtmp file.  Of course, as soon as some crackpot tries to copy or
> edit+save the binary (somehow changing the binary), Linux will drop
> the setuid bit :)  This prevents a public xterm binary from transforming
> into a root shell, and other nasty security holes like that.
> 
> Normally, xterm will use its root power to just include the user in
> the wmtp file, so that they show up in who and finger.  After doing
> this, it adopts the privileges of the user for the duration of its
> life.  As xterm closes, it returns to root to remove the user from
> the wtmp file (logged out), then closes.
> 
> There was a security alert a long while ago where giving xterm an
> extremely long window title caused a buffer overflow and allowed
> arbitrary execution of code (from the tail of the overflow) with
> root privileges.  One of the many reasons why setuid'ing programs
> is best avoided unless absolutely necessary.
> 
> Anyway, rxvt and derivatives are *not* installed setuid for security
> reasons, mainly things like buffer-overflows or other obscure exploits
> to cause code to execute as root.  Because these terminals never get
> root access, they can never get access to the wtmp file.  Thus, you
> never appear on the list of who's logged in.
> 
> 
> However, rxvt and friends do understand the wtmp file.  When configured
> to do so ("./configure"), and when it is setuid root, it will handle the
> wtmp entries properly.  I believe distribution-made versions are already
> configured for wtmp, and just need to have the setuid set to write wtmp.
> 
> 
> Alternatively, instead of setuid'ing the programs, change permissions
> on the wtmp file accordingly, like let yourself write to it :)
> This is feasibly especially if it's just your personal machine.
> Better to have a trash-filled wtmp (which you can just delete) than
> to have a trash-filled disk (which ... would be really nasty).
> (Perhaps chgrp'ing it to your group, then chmod g+w ?)
> 
> 
> The even cleaner way is with PAM (Pluggable Authentication Modules)...
> but I'm trying to learn about that myself.  PAM (having root access) can
> alter wtmp on behalf of a non-setuid program, so that (badly-written?)
> setuid programs can't compromise the system as easily.  This means that
> programs would not need to be setuid to write to wtmp, which can stay
> owned by root.  However, programs need to be specifically written to
> support PAM (through libraries and API's), so the original programs
> need to be modified as well.  AFAIK, that's not exactly an option at
> this point in time.
> 
> 
> 
> Now taking in a long deep breath,
> -Fred
> 
> _______________________________________________
> UCLALUG Linux mailing list - Linux@linux.ucla.edu
> http://linux.ucla.edu/mailman/listinfo/linux
> 
> 

-- 
boykin@pobox.com	http://pobox.com/~boykin	ICQ: 5118680
Key fingerprint = 159A FA02 DF12 E72F B68F  5B2D C368 3BCA 36D7 CF28