Xref: utzoo comp.sys.att:8448 unix-pc.general:4483
Path: utzoo!attcan!telly!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Uniquely identifying a user: is it possible?
Summary: well enough for me
Message-ID: <1990Jan11.214102.18162@eci386.uucp>
Date: 11 Jan 90 21:41:02 GMT
References: <25730@cup.portal.com>
Reply-To: woods@eci386.UUCP (Greg A. Woods)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 50

In article <25730@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
> Recently there have been 3 different programs posted which, among other things,
> report the last-login date-and-time of a user on a SystemV system:
> 
> Each program uses different strategies, and each has a related problem!

My version (lastlog) is complete and sufficient for the purposes it was
designed for, and it is reasonably difficult to subvert its intentions
in a well managed system.

1. lastlog should be placed in /etc/profile, as I suggested in the
readme.  In this environment, it functions correctly and is always
called (except for uucp logins, though this can be remedied by writing
a shell around uucico).  The normal case of a user executing lastlog
after his session has started is harmless, since the effect is nil.

2. lastlog cannot be fooled into reporting on a different utmp line,
since to fool ttyslot(3c), one would have to have read permission on
another tty with a current utmp entry.  I make the assumption that
other ttys should never be readable by the average user.  Further
checking could be done to assert the current uid matched the one in
the utmp entry.

3. If someone fools lastlog by using a different uid, then either your
system has a bad security hole, or that user knows another's password.
In any case there is no loss of information; current information for
the subverted user's id is recorded.  It would be nice if su knew
about lastlog too.

4. lastlog information cannot be deleted by the average user.  This is
the most important point for me.  The SysVr3.2 login keeps similar data
in the ctime of the inode for the .lastlogin file in each user's home
directory.  Although you cannot set this value to represent some date
in the past, this scheme is still not perfect.  If file is deleted,
you know only that a break in to your account was attempted, but it is
not easy to determine when it occured, though the ctime of your home
directory might be a clue.

One of the reasons I wrote lastlog and ported finger was because they
provide one of the simple security related features of BSD that I
really missed in the SysV world.  Perhaps someday I'll write my own
login replacement for SysV (which isn't actually that difficult, I've
done it for V7), and be done with the uncertainty of a user-accessable
lastlog programme.
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET}
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3-TCP	Toronto, Ontario CANADA