What are reasonable blockers for making journald the default logger in F19?

Simo Sorce simo at redhat.com
Wed Oct 17 20:19:45 UTC 2012


On Wed, 2012-10-17 at 16:01 -0400, Andrew Schultz wrote:
> Matthew Miller wrote:
> > On Wed, Oct 17, 2012 at 03:07:19PM -0400, Andrew Schultz wrote:
> >> and if you log all attempts to login, then they'll end up in the
> >> logs.  I'd suggest that not logging unknown users by default is a
> >> much better solution than having a special log; no admin wants to
> >> see passwords (even if they're root) and unknown usernames (either
> >> typos or passwords) are rarely helpful.
> >
> > I don't think that's true. "You're typing the wrong username" happened to me
> > on multiple occasions when I was doing that kind of support.
> 
> I don't have a problem with logging the fact that a user attempted to 
> log in with an unknown username, and that would be sufficient for the 
> your diagnosis (if you can correlate times).  If you can't correlate 
> times, then you get to scrape the logs looking for similar but invalid 
> usernames.  A simple "what user name are you trying to log in as?" would 
> go much faster.
> 
> > Additionally, it maybe useful to log this information for intrusion
> > detection and correlation.
> 
> Again, you don't need to know that the attacker guessed a username of 
> "bob".  You simply need to recognize that N attempts were made to log in 
> with unknown usernames during some time period.
> 
> > And, in general, authpriv exists as a mechanism for logging any sort of
> > potentially private data. It would be a security regression to ignore that.
> 
> Not seeing useless (typos) and confidential (passwords) information is 
> not a security regression.  And I'm having trouble thinking of other 
> information that is super-private (should only be seen by root) and useful.

All very nice, but the current situation is that this info *is* sent to
the log.
So I applaud if you want to go and fix applications, in the meanwhile we
cannot relax security around that log IMO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list