Misleading security message output
rees at ddcom.co.jp
Thu Apr 21 19:39:50 PDT 2005
> > The first question that comes to mind: do you really need logs from a
> > year back?
> Nope. Should I need to tweak the default config files to ensure
> that I dont get them?
Since that's the element that brings three possible mis-features
together in the unfortunate interaction, and is also the element that
you have the most direct and immediate control over, and also should not
be a difficult fix, I would sure see it as the tempting fix.
I think I'd also want to submit a feature request to whoever is
currently claiming the program that generates the logs.
> > Maybe it's because I'm such a newb, but I'm wondering which program has
> > what bug? Is it that the default configuration files for the login logs
> > doesn't put on age limit on the rotation? Is it that the log lines don't
> > conain a full 4-digit year in the timestamp? Or is it that the
> > logscraper doesn't know to check the age of a log file, or doesn't know
> > to work on the tail of the log?
> The bug is in the security logscraper script, because it
> presented a log entry from a year ago as something that happened
The way I see it, that's less where the bug is and more where the bugs
> The proximate cause of the bug is that the log
> files don't contain a year as part of the date format. The
> easy work-around is to include timed rotation as part of the
> standard configuration so that the lack of a year in the logfile
> date format does not expose the bug in the script. There are
> two plausible "real fixes" for the bug: 1) use a backup+diff
> scheme to find "yesterday's log messgaes" -- this is what NetBSD
> does, or 2) change the syslog daemon to include the year in the
> logfile date stamp -- this is what daemontools' multilog does.
> Option 2 is likely to be difficult to roll into the standard
> because it would almost certainly break third-party logfile
I'm thinking that the logscrapers are likely not to be going to the
trouble of grabbing only two digits out of the year field, but I
probably don't see as much code as you do.
I see I'm preaching to the choir, and that we just have different points
of view about how deep you want to reach into freeBSD to fix your bug.
Joel Rees <rees at ddcom.co.jp>
digitcom, inc. 株式会社デジコム
Kobe, Japan +81-78-672-8800
** <http://www.ddcom.co.jp> **
More information about the freebsd-stable