Bug 2039730
Summary: | sys_ptrace AVC seen when sssd_nss tries to check user's systemd instance /proc/xxx/cmdline when hidepid=2 is used | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> |
Component: | sssd | Assignee: | Alexey Tikhonov <atikhono> |
Status: | CLOSED WONTFIX | QA Contact: | sssd-qe <sssd-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.5 | CC: | aboscatt, atikhono, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, sbose, tscherf, zpytela |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-01-24 20:17:53 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: |
Description
Renaud Métrich
2022-01-12 10:19:07 UTC
There are two places where SSSD reads /proc/ : (1) This ticket is about this place: https://github.com/SSSD/sssd/blob/4897c28741112b547a69feb7c887764c64cc9540/src/responder/common/responder_common.c#L133 This is for a better debug purposes only. No functionality affected if this read fails. I.e. "which seem to prevent normal operations to complete" shouldn't be the case. What is the expected result of a potential "fix" here? (2) But there is also read of "/proc/%d/status": https://github.com/SSSD/sssd/blob/4897c28741112b547a69feb7c887764c64cc9540/src/util/find_uid.c#L74 Do I understand correctly this "hidepid=2" mount option will make this read to fail as well? This is a more serious issue as this can affect KRB auth. Hello, Given that in BZ #2038929 using hidepid is not supported with systemd-239, we may put this on hold or lower priority. Renaud. Hi Zdenek, (In reply to Alexey Tikhonov from comment #1) > There are two places where SSSD reads /proc/ : > > (1) This ticket is about this place: > https://github.com/SSSD/sssd/blob/4897c28741112b547a69feb7c887764c64cc9540/ > src/responder/common/responder_common.c#L133 > > This is for a better debug purposes only. No functionality affected if this > read fails. What would be a recommended approach in this case from 'selinux-policy' team point of view? "This case": - SSSD tries to read /proc/$pid for debug purposes only - read fail, but we don't care (just this bit of info is missing in the debug message) - but this generates AVC errors Hi, I wonder if adding CAP_SYS_PTRACE to CapabilityBoundingSet, e.g. in /usr/lib/systemd/system/sssd.service but better with a snippet in /usr/lib/systemd/system/sssd.service.d/ ? bye, Sumit (In reply to Sumit Bose from comment #4) > Hi, > > I wonder if adding CAP_SYS_PTRACE to CapabilityBoundingSet, e.g. in > /usr/lib/systemd/system/sssd.service but better with a snippet in > /usr/lib/systemd/system/sssd.service.d/ ? This might be a solution for comment 1 :: (2) This solution obsoletes my question in comment 3, of course, but still I'd like what should be an approach to solve (1). I mean, additional debug isn't good enough justification for CAP_SYS_PTRACE, from my point of view. (In reply to Alexey Tikhonov from comment #3) > > There are two places where SSSD reads /proc/ : > > > > (1) This ticket is about this place: > > https://github.com/SSSD/sssd/blob/4897c28741112b547a69feb7c887764c64cc9540/ > > src/responder/common/responder_common.c#L133 > > > > This is for a better debug purposes only. No functionality affected if this > > read fails. > > What would be a recommended approach in this case from 'selinux-policy' team > point of view? > > "This case": > - SSSD tries to read /proc/$pid for debug purposes only > - read fail, but we don't care (just this bit of info is missing in the > debug message) > - but this generates AVC errors I may not completely understand this case down to details, so giving more of a generic answer. 1. Leave everything as is. For debug processes to succeed, create a custom policy. 2. selinux-policy will add supportive rules when a boolean, like sssd_debug, is turned on, being off by default. 3. selinux-policy will add such rules unconditionally. It means the "debug purposes" statement need to be assessed properly. How often it happens? Under which conditions? Who is expected to do that (RH maintainer, RH support, systems administrator, user, ...)? In the case of "read fails, but we don't care" it seems more like the option 1 is the most appropriate. Hi Renaud, Could you please clarify "which seem to prevent normal operations to complete" / bz 2038929#c4 "sssd_nss doesn't seem to work anymore"? What operations doesn't work anymore? Actually I don't know if anything is impacted here, it's very possible it's just cosmetic, I don't have a real setup with remote users. (In reply to Alexey Tikhonov from comment #5) > (In reply to Sumit Bose from comment #4) > > > > I wonder if adding CAP_SYS_PTRACE to CapabilityBoundingSet, e.g. in > > /usr/lib/systemd/system/sssd.service but better with a snippet in > > /usr/lib/systemd/system/sssd.service.d/ ? > > This might be a solution for comment 1 :: (2) Having thought about this more, I don't think we should unconditionally add new capability (i.e. worsen security) for the sake of very rare use case. And attempt to condition this capability based on mount option (or fail to read, or whatsoever) would be too cumbersome and not worth the effort, imo. Users interested in such a system hardening should make a decision and either add this capability on their own, or accept some reduction of functionality (delayed krb auth, pam_initgroups_scheme=no_session, ...) I'm inclined to close this as "NOTABUG" if there will be no objections. Closing as a follow up to comment 9. Please reopen in case of disagreement. |