RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2039730 - sys_ptrace AVC seen when sssd_nss tries to check user's systemd instance /proc/xxx/cmdline when hidepid=2 is used
Summary: sys_ptrace AVC seen when sssd_nss tries to check user's systemd instance /pro...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Alexey Tikhonov
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-12 10:19 UTC by Renaud Métrich
Modified: 2022-01-24 20:18 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-24 20:17:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-107552 0 None None None 2022-01-12 10:23:58 UTC
Red Hat Issue Tracker SSSD-4258 0 None None None 2022-01-13 15:27:33 UTC

Description Renaud Métrich 2022-01-12 10:19:07 UTC
Description of problem:

Some customers used "hidepid=2,gid=xxx" in the past (up to RHEL7) to hide processes from other users.
With RHEL8, when setting such option, we can see sys_ptrace AVC, which seem to prevent normal operations to complete, e.g.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
type=PROCTITLE msg=audit(01/10/2022 15:35:32.650:49) : proctitle=/usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files 
type=SYSCALL msg=audit(01/10/2022 15:35:32.650:49) : arch=x86_64 syscall=openat success=no exit=ENOENT(No such file or directory) a0=0xffffff9c a1=0x7ffe06a54920 a2=O_RDONLY a3=0x0 items=0 ppid=1133 pid=1213 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=sssd_nss exe=/usr/libexec/sssd/sssd_nss subj=system_u:system_r:sssd_t:s0 key=(null) 
type=AVC msg=audit(01/10/2022 15:35:32.650:49) : avc:  denied  { sys_ptrace } for  pid=1213 comm=sssd_nss capability=sys_ptrace  scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:sssd_t:s0 tclass=capability permissive=0 
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Here above "sssd_nss" tries to open /proc/XXX/cmdline to verify the command line, which is typically used to verify who connects to the sssd Unix socket: this happens for "systemd --user" instances which do some sssd query.

Kernel guys confirmed through BZ #2038929 that the "hidepid=2" /proc functionality is supported and useful.

Version-Release number of selected component (if applicable):

RHEL8.5 sssd

How reproducible:

Always


Steps to Reproduce:

1. Set options in /etc/fstab

  proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2,gid=1000 0 0

2. Enable sssd

  # yum -y install sssd
  # authselect select sssd

3. Reboot and log in as some user

Actual results:

AVCs

Comment 1 Alexey Tikhonov 2022-01-12 11:47:24 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.

Comment 2 Renaud Métrich 2022-01-13 15:40:07 UTC
Hello,

Given that in BZ #2038929 using hidepid is not supported with systemd-239, we may put this on hold or lower priority.

Renaud.

Comment 3 Alexey Tikhonov 2022-01-13 17:15:32 UTC
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

Comment 4 Sumit Bose 2022-01-13 17:26:37 UTC
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

Comment 5 Alexey Tikhonov 2022-01-13 17:41:50 UTC
(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.

Comment 6 Zdenek Pytela 2022-01-13 17:43:55 UTC
(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.

Comment 7 Alexey Tikhonov 2022-01-13 17:49:29 UTC
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?

Comment 8 Renaud Métrich 2022-01-13 19:21:22 UTC
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.

Comment 9 Alexey Tikhonov 2022-01-14 11:44:02 UTC
(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.

Comment 10 Alexey Tikhonov 2022-01-24 20:17:53 UTC
Closing as a follow up to comment 9. Please reopen in case of disagreement.


Note You need to log in before you can comment on or make changes to this bug.