Bug 1287800
Summary: | RFC: audit log prevents PAM login when euid != uid | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Paulo Andrade <pandrade> |
Component: | pam | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.1 | CC: | cww, dapospis, pandrade, pkis, roland.kaiser, sgrubb, tmraz |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | pam-1.1.8-14.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-04 03:31:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1203710, 1296594, 1313485 |
Description
Paulo Andrade
2015-12-02 17:22:14 UTC
This is a very confusing bug report. So, you are saying that the user has a perl script that connects to a system and tries to authenticate and pam does not allow the script to access the system? What login service is this script connecting to? I understand it is difficult to understand the description. I tried to list my findings debugging the script, and where the error code came from. The error code comes from the recvfrom call in audit_get_reply. The message of success in pam authentication is printed to /var/log/audit/audit.log but after that, due to the recvfrom call, it ends with pam error code PAM_SYSTEM_ERR The RFC bug is to try to ask for some feedback, as I have very few knowledge of pam and audit, just tried to describe as much as possible what was going on. From my understanding, if pam were not built with audit support, it likely would work, like the user says, it works on Solaris. Maybe Roland Kaiser, the user with the problem :), can make some extra comments? Is the perl script connecting to a system or is it a service that clients are connecting to? If its connecting to a system, I need to know what the service is to see what's wrong with it. If the script is the service authenticating clients, then it needs to have CAP_AUDIT_WRITE. The perl Script is a Service which is intended to authenticate incoming radius requests against an externel Active Directory using Kerberos. So it is Kind of both... What is CAP_AUDIT_WRITE and how do I enable it? CAP_AUDIT_WRITE is a posix capability. But before we go there, what uid & euid is the service running as when its hits this piece of code? This happens when uid=0 and euid=70 It works if uid=euid=0 or uid=euid=70 Steve, do you have an update for me? The pam code has a loophole like this: if (rc < 0) { if (rc == -EPERM && getuid() != 0) return 0; In reality, the getuid() != 0 is a quick and dirty replacement for checking the capabilities for CAP_AUDIT_WRITE. This is intended to be used by screensaver applications which run as the user and could not have the right capability. Looking at man 7 capabilities, "Effect of user ID changes on capabilities", there is this section: 2. If the effective user ID is changed from 0 to nonzero, then all capabilities are cleared from the effective set. I'm wondering if the loophole for screensavers should be using geteuid() != 0. The question is whether the loophole should not be simply rc == -EPERM - is there any other possible circumstance than missing CAP_AUDIT_WRITE where the audit call would return -EPERM? The only thing I can think of in terms of pam is if selinux blocked it for some reason. selinux is disabled (triplechecked it...) Can I disble writing to Audit somewhere - or - can I disable the cap_audit_write check globally just to test? Even though you have disabled it, we have to take into consideration everyone that uses it. You really ought to have it on but have your daemon in a permissive domain until there is policy for it. This way you have both selinux protection for most of the system and flexibility to run new things. That said, I think the correct fix is to change pam's code as Tomas mentioned. I will also change the audit library over to using geteuid() for its checks. But libaudit is not your problem in this particular case. Moved this to pam to get the specific problem above fixed in the right component. Similar cases of this issue were fixed in the audit package with upstream commit 1135. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2314.html |