Bug 2137171
| Summary: | /proc/PID/io should be world readable, like i.e. /proc/PID/status | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Christian Horn <chorn> |
| Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> |
| kernel sub component: | Other | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Status: | CLOSED NOTABUG | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | dbohanno, nathans, onestero |
| Version: | unspecified | Keywords: | RFE |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| 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-10-26 14:56:02 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: | |||
(In reply to Christian Horn from comment #0) > > - We think /proc/PID/io should have wider permissions, like > /proc/$$/{status,mounts,smaps,stat} and other files. > We just could not directly come up with a good reason to > have /proc/PID/io readable to owner/root only. Well. The upstream commit 1d1221f375c94ef96 ("proc: restrict access to /proc/PID/io") says: /proc/PID/io may be used for gathering private information. E.g. for openssh and vsftpd daemons wchars/rchars may be used to learn the precise password length. Restrict it to processes being able to ptrace the target process. ptrace_may_access() is needed to prevent keeping open file descriptor of "io" file, executing setuid binary and gathering io information of the setuid'ed process. This is CVE-2011-2495, btw. So I think we should close this bug as NOTABUG. If you think that the patch above was wrong and can be reverted, please forward your concerns to lkml and/or security. Closing BZ due to the justification given in comment 1. -David This is a very unfortunate situation, and while I can understand the concerns listed in the CVE an inverse security problem is also happening - many people are forced to run performance tools in insecure modes (i.e. as privileged users, incl. daemons running as root) because they need access to this information to solve performance problems. I wonder if a compromise solution could work, where the permissions could be configurable e.g. via a sysctl setting, to allow sysadmins to choose what is going to work best for individual systems? Regarding the referenced kernel commit and specifically "Restrict it to processes being able to ptrace the target process." - I experimented with trying to give CAP_SYS_PTRACE to userspace processes, but haven't been able to make it work. If we can figure this out, perhaps this is an avenue we can explore to provide the sysadmin-opt-in mechanism. If anyone can see what I've missed here, please let me know ... thanks. $ sudo setcap cap_sys_ptrace=eip /usr/bin/cat $ getcap /usr/bin/cat /usr/bin/cat cap_sys_ptrace=eip $ $ /usr/bin/cat /proc/1/io /usr/bin/cat: /proc/1/io: Permission denied $ sudo /usr/bin/cat /proc/1/io rchar: 594562382077 wchar: 182137796785 syscr: 791652377 syscw: 199627602 read_bytes: 111509180928 write_bytes: 142228922368 cancelled_write_bytes: 6872858624 $ $ sudo setcap -r /usr/bin/cat $ getcap /usr/bin/cat $ Should this work? I was hopeful based on reading kernel/ptrace.c along with capabilities(7), setcap(8) and cap_from_text(3). (In reply to Nathan Scott from comment #4) > > $ sudo setcap cap_sys_ptrace=eip /usr/bin/cat > $ getcap /usr/bin/cat > /usr/bin/cat cap_sys_ptrace=eip > $ > > $ /usr/bin/cat /proc/1/io > /usr/bin/cat: /proc/1/io: Permission denied Well, I know absolutely nothing about capabilities ;) But. Yes you need CAP_SYS_PTRACE, otherwise the ptrace_may_access() check in do_io_accounting() will fail. However, do_io_accounting() is called by sys_read() paths, you need to open the file first and open("/proc/1/io", O_RDONLY) obviously fails. CAP_DAC_READ_SEARCH=2 + CAP_SYS_PTRACE=19 seems to work: # setcap 2,19=eip ./cat $ ~root/cat /proc/1/io rchar: 88739747832 wchar: 11804927869 syscr: 91425808 syscw: 35006320 read_bytes: 2993438720 write_bytes: 6539235328 cancelled_write_bytes: 537047040 Aha - very helpful, thanks Oleg. |
Description of problem: /proc/PID/io should be world readable, like i.e. /proc/PID/status Version-Release number of selected component (if applicable): latest kernel How reproducible: Always Steps to Reproduce: 1. ls -al /proc/$$/io Actual results: -r--------. 1 chris chris 0 Oct 24 07:17 /proc/12254/io Expected results: -r--r--r--. 1 chris chris 0 Oct 24 07:17 /proc/12254/io Additional info: - We think /proc/PID/io should have wider permissions, like /proc/$$/{status,mounts,smaps,stat} and other files. We just could not directly come up with a good reason to have /proc/PID/io readable to owner/root only. - To restrictive permissions actually cause a decrease in security because userspace tools have to run as root to read them, instead of running unprivileged - Practically, how this was hit recently: using the Performance Co-Pilot framework, one can nicely use 'pcp atop -d' to identify the processes doing most I/O. When using logging into archive files with PCP, the files under /proc are just read by an unprivileged user, so looking up 'who did how much I/O last week Tuesday 2am' is then not conveniently possible.