solaris lastlog truncation?
Greg
Just noticed that my solaris box is giving me only the last people
logged in since yesterday and I haven't messed with lastlog, wtmp, etc.
My previous experience with Solaris (2.6) is that you needed to
manually delete these old log files, and I'm a it concerned that
someone may have hacked in. Can someone please confirm for me that
these logs are not self-truncating.
Thanks a million.
Greg
Casper H.S. Dik - Network Security Engineer
Greg <jqu...@shell7.ba.best.com> writes:
None of the *tmp* logs are self-truncating.
(Lastlog, in fact, never grows and doesn't need to be truncated)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Richard L. Hamilton
of an array of the data structures in /usr/include/lastlog.h,
indexed by uid. AFAIK, nothing truncates it (or needs to).
Since it is a sparse file, it probably uses much less space
than it appears to. That's where login(1) gets the information
to print a line like:
Last login: Sat Feb 27 05:10:13 from localhost
To demonstrate just how sparse it is, look at this:
$ ls -ls /var/adm/lastlog
64 -r--r--r-- 1 root other 406196 Feb 27 05:10 /var/adm/lastlog
Even though the size would make you think that it could be using 794
512-byte blocks, in this case it's only actually using 64, the rest being
"holes" that appear as hunks of zero bytes when the file is read. (My system
just serves me, a couple of infrequent guest users, and a few pseudo accounts,
none of which are all that high numbered, but the numbers are nowhere near
consecutive. The file size will be that of the highest uid number to have
logged in (or ftp'd in, perhaps), multiplied by the size of the data
structure in lastlog.h How sparse it is will be determined by how sparse
the uids up to that maximum that have actually logged in are.
/var/adm/wtmp and /var/adm/wtmpx are AFAIK only truncated if one runs
process accounting (typically the /usr/lib/actt/runacct in adm's crontab),
if one has some other cron job to clobber or archive them, or if someone
truncated them by hand.
It can sometimes happen that one of the two is truncated and the other
isn't (whether by human error or disk problems). I've seen this (at least
in prior versions of Solaris) confuse who(1), which expected them to be
in reasonable synch with each other.
Accounting typically runs closewtmp(1m) to fake logout entries into wtmp,
captures the data in wtmp, and then runs utmp2wtmp(1m) to make it look like
everyone logged right back in again. That way, accounting doesn't have
to deal with the problem of people that stay logged in across accounting
runs. utmp2wtmp(1m) only shortens wtmp, not wtmpx, but I have a version
of utmp2wtmp that I did that can be compiled to consistently do its job
on wtmpx as well as wtmp. Otherwise, barring something else to clean it out,
even if you run accounting, wtmpx will probably grow until you run out
of space.
If anyone other than you has root, they might have clobbered one or more
of wtmp, wtmpx, or lastlog to free space in /var (or /var/adm if that's
a separate filesystem). Clobbering lastlog is generally pointless since
it is sparse, but not everyone knows that.
A crash just at the wrong time could just conceivably have truncated
them, but that's pushing a point. I'd be particularly inclined to
eliminate that explanation if more than one of them were truncated, and
in any case, you should have other log entries that would reveal either
crashing or running out of space in a partition.
If none of the above explains it, then you may well have been broken
in to.
In article <36d74d81$0$1...@nntp1.ba.best.com>,
Greg <jqu...@shell7.ba.best.com> writes:
> I'm concerned about a potential security breach:
> Just noticed that my solaris box is giving me only the last people
> logged in since yesterday and I haven't messed with lastlog, wtmp, etc.
> My previous experience with Solaris (2.6) is that you needed to
> manually delete these old log files, and I'm a it concerned that
> someone may have hacked in. Can someone please confirm for me that
> these logs are not self-truncating.
>
> Thanks a million.
> Greg
>
--
ftp> get |fortune
377 I/O error: smart remark generator failed
Bogonics: the primary language inside the Beltway
mailto:rlh...@mindwarp.smart.net http://www.smart.net/~rlhamil
Sheldon T. Hall
>/var/adm/wtmp and /var/adm/wtmpx are AFAIK only truncated if one runs
>process accounting (typically the /usr/lib/actt/runacct in adm's crontab),
>if one has some other cron job to clobber or archive them, or if someone
>truncated them by hand.
Speaking of wtmp* ... wmtpx, as reported by the last program, doesn't seem
to record logins via Xterms.
I.e. if I telneted in, last will show I was there, but if I used an Xterm
emulator to log in, last seems to ignore the login completely. Both logins
are from the same Win95 box, connected on my LAN, and logging into an IPX
running Sol 7.
Is there some setting I've overlooked?
-Shel
--
Sheldon T. Hall
7670...@compuserve.com
This message sold by weight, not by volume;
Content may have settled during shipment.
Casper H.S. Dik - Network Security Engineer
7670...@compuserve.com (Sheldon T. Hall) writes:
>Speaking of wtmp* ... wmtpx, as reported by the last program, doesn't seem
>to record logins via Xterms.
I don't think this was ever a standard feature in xterms; I seem to remember
having to enable it explcitely in X11R5 xterm.
In fact, the Imakefile says:
* add -DWTMP and -DLASTLOG if you want them; make sure that bcopy can
>I.e. if I telneted in, last will show I was there, but if I used an Xterm
>emulator to log in, last seems to ignore the login completely. Both logins
>are from the same Win95 box, connected on my LAN, and logging into an IPX
>running Sol 7.
>Is there some setting I've overlooked?
No, it's the standard X consortium xterm behaviour.
Stefan Monnier
> Speaking of wtmp* ... wmtpx, as reported by the last program, doesn't seem
> to record logins via Xterms.
Do you mena X terminals or do you mean `xterm' programs ?
The `xterm' program cannot be used to login (it can only be used once you log
in), so it has not reason to add any entry in the wtmp files.
Now for the X terminals, the display manager (xdm or whatever its name)
should indeed add the entry to wtmp (and it does here using XFree86's xdm).
Stefan
Sheldon T. Hall
Network Security Engineer) wrote:
>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
>
>7670...@compuserve.com (Sheldon T. Hall) writes:
>
>>Speaking of wtmp* ... wmtpx, as reported by the last program, doesn't seem
>>to record logins via Xterms.
>
>I don't think this was ever a standard feature in xterms; I seem to remember
>having to enable it explcitely in X11R5 xterm.
[snip]
>>Is there some setting I've overlooked?
>
>No, it's the standard X consortium xterm behaviour.
Doesn't this non-logging of Xterm logins constitute a bit of non-security?
Casper H.S. Dik - Network Security Engineer
7670...@compuserve.com (Sheldon T. Hall) writes:
>Doesn't this non-logging of Xterm logins constitute a bit of non-security?
Perhaps, but xterm "logins" cannot happen in the normal sense of the word.
You need to get on the system first. I believe PC X clients often use rexecd
or even rshd to access the system; the problem that no login logging happens
lies with those services.
If you use a remote X access system like xdm or dtlogin, you do get wtmp
entries.
Sheldon T. Hall
<monnier+comp/security/unix/news/@tequila.cs.yale.edu> wrote:
>>>>>> "Sheldon" == Sheldon T Hall <7670...@compuserve.com> writes:
>> Speaking of wtmp* ... wmtpx, as reported by the last program, doesn't seem
>> to record logins via Xterms.
>
>Do you mena X terminals or do you mean `xterm' programs ?
>The `xterm' program cannot be used to login (it can only be used once you log
>in), so it has not reason to add any entry in the wtmp files.
>Now for the X terminals, the display manager (xdm or whatever its name)
>should indeed add the entry to wtmp (and it does here using XFree86's xdm).
I mean an Xterm emulator running on a PC.
Specifically, it's Xwin32 running under Win95.
Xwin32 connects via rexec, using a username and password valid on the system
to which it's connecting, and executes a command line, in my case
/usr/openwin/bin/xterm -ls -display $DISPLAY &
where "$DISPLAY" is an Xwin32-ism that resolves to my PC's IP address,
screen, etc.
This gives me access to the Solaris system, without generating any entries
in the wtmpx file. I can log on as root this way, and have full root
powers. Casper says that's the way it's supposed to be, but it seems like a
design fault to me.
Geoffrey KEATING
> Xwin32 connects via rexec, using a username and password valid on the system
> to which it's connecting, and executes a command line, in my case
>
> /usr/openwin/bin/xterm -ls -display $DISPLAY &
>
> where "$DISPLAY" is an Xwin32-ism that resolves to my PC's IP address,
> screen, etc.
>
> This gives me access to the Solaris system, without generating any entries
> in the wtmpx file. I can log on as root this way, and have full root
> powers. Casper says that's the way it's supposed to be, but it seems like a
> design fault to me.
Surely the problem is that rexec isn't logging, not that xterm isn't logging?
It's rexec that's giving you access, not xterm; if you wanted,
you could just send your commands across to rexec, and avoid X altogether.
--
Geoff Keating <Geoff....@anu.edu.au>
Casper H.S. Dik - Network Security Engineer
7670...@compuserve.com (Sheldon T. Hall) writes:
>This gives me access to the Solaris system, without generating any entries
>in the wtmpx file. I can log on as root this way, and have full root
>powers. Casper says that's the way it's supposed to be, but it seems like a
>design fault to me.
It's perhaps a design problem, but auditing will catch this.
What I said is that it's not an xterm problem; you're already on the
system when you start xterm.
(Both rshd and rexecd let you on the sytem w/o wtmp trail)
Juergen Marenda
Sheldon T. Hall
Network Security Engineer) wrote:
>It's perhaps a design problem, but auditing will catch this.
>
>What I said is that it's not an xterm problem; you're already on the
>system when you start xterm.
>
>(Both rshd and rexecd let you on the sytem w/o wtmp trail)
You're right. I suppose the Xterm part is a mere symptom of the underlying
rexec disease....
Thanks for the explanation and the expansion.