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

Lennart Poettering mzerqung at 0pointer.de
Wed Oct 17 18:39:34 UTC 2012


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".

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

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.

> 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".

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list