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

[Simo Sorce]

On Wed, 2012-10-17 at 20:39 +0200, Lennart Poettering wrote:
> On Wed, 17.10.12 12:58, Simo Sorce (simo at redhat.com) wrote:
> 
> > On Wed, 2012-10-17 at 17:45 +0200, Lennart Poettering wrote:
> > > On Wed, 17.10.12 10:44, Matthew Miller (mattdm at fedoraproject.org) wrote:
> > > 
> > > > 2. Mechanism for separation of authpriv data 
> > > 
> > > Humm, so, I have my doubts that this really is desirable...
> > > 
> > > "because syslog did it this way too" doesn't sound like a really good
> > > reason for this.
> > 
> > No you are getting it wrong here.
> > 
> > It's not that syslog did it this way.
> > 
> > But syslog was configured explicitly this way and on purpose, if it were
> > logsys instead of syslog we'd still have the same configuration done by
> > the maintainers of the distro.
> > 
> > The point is that the authpriv target gets data from pam/login
> > applications and it is *normal* to have leaked password sin there.
> > So it should not be readable by anyone but root.
> > Or a leaked password suddenly becomes a privilege escalation issue
> > instead of just an annoyance.
> 
> So, that passwords are logged to authpriv appears to be fabrication to
> me. Can you point me to something reliable that people understood it
> that way, that code is actually doing this, or even best, that authpriv
> was actually supposed to be used for logs like that?
> 
> To my knowledge AUTHPRIV is simply for authorization-related data, not
> for the seccret auth tokens themselves. The Linux man page suggests that
> AUTH is obsolete, and AUTHPRIV is what people should use for all auth
> related stuff. And if things get specific this is mostly about "user
> logged in", "user changed password", but never "user changed password
> to xyz".

Sigh, I guess I need to be more explicit, you can find messages like:

User MySecretPassword failed authentication.

Because mistakenly a user typed his password at the login prompt instead
of his name. It is common.

> Can you back up your claim that AUTHPRIV is supposed to be good for
> logging passwords, or that existing code uses it that way?

No because that is not the claim, I said LEAKED, not shown on purpose.

> If that's not the case then it should be sufficient to protect the
> journal files that non-privileged users can't read them, and only users
> in the special group "adm" can. That is already quite a stringent
> protection. I mean, I am not suggesting making anything
> world-readable. These files are only readable by "adm" users, i.e. users
> deemed trustable enough to read system logs.

adm is not root, if root leaks his password there then you have a
problem  if users in adm can read it.

> > It is superduper necessary by default, because you can't close the barn
> > *after* the sheep have escaped.
> 
> Well, the sheep won't escape anyway since normal users are not in
> "adm". You better know what you do if you add a user to "adm".

If you trust the user ultimately you give him root, if you put it in adm
instead it is because you do not trust him with the root password.
Se the example above and connect the dots.

Simo.

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