New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
su to radiusd user/group when rotating logs #2666
Conversation
The su directive to logrotate ensures that log rotation happens under the owner of the logs. Otherwise, logrotate runs as root:root, potentially enabling privilege escalation if a RCE is discovered against the FreeRADIUS daemon. Signed-off-by: Alexander Scheel <ascheel@redhat.com>
|
Could you do a similar PR for master |
|
Happy to, will do. Thanks! |
|
CVE-2019-10143 has been assigned to this issue. |
|
@ret2libc What security issue mandates a CVE? I'm not sure there's a need for a CVE which has no current way to exploit it. Are we issuing CVEs now for potential issues? |
|
@alandekok we are aware of a way to exploit this, though it requires the attacker to already have "high privileges" (that is, he needs to have access to the radiusd user) |
|
@ret2libc " we are aware of a way to exploit this" Uh... any thought that you might tell us about this? The email address Is it common RedHat security practice to file for a CVE, and then never tell the authors about it? On top of that, I'm skeptical of "security" issues which require already privileged access. If the "attacker" has access to the radiusd user, then he can run the RADIUS server, and authenticate anyone he wants. That's a huge security problem, too. So maybe you need to issue another CVE saying "someone running as radiusd can run the RADIUS server"! I'm more than a bit surprised at this process. It's utterly bizarre to not inform the authors of an issue, and file for a CVE without giving the authors any prior notification. We will be issuing a PGP signed vendor statement about this process, along with our opinion of the validity of the CVE. Do you have any feedback which mitigates the disastrous process you've used here? |
Sorry for not using your security email first, but the issue was already public
For "a way to exploit this", you can see the reproducer in the first comment of
As you said, the flaw has limited impact, since it requires the attacker to
We do have very careful security response processes in place, but I agree in |
The
sudirective tologrotateensures that log rotation happens under theowner of the logs. Otherwise,
logrotateruns asroot:root, potentiallyenabling privilege escalation if a RCE is discovered against the
FreeRADIUS daemon.
This attack avenue seems quite unlikely to me. The other alternative is making the
/var/log/radiusddirectory owned by root. It seems like thelogrotatemethod is better hygiene though. Thoughts?Signed-off-by: Alexander Scheel <ascheel@redhat.com>