Bug 1336211

Created attachment 1157821 [details]
audit.log

Investigating this further, it's not necessarily only about SELinux policy tuning - for example, why PCP wants to access several files under users' home directories?

The attached audit.log generated by having pmcd running (no pmlogger in play) and doing pminfo -f as root.

Hi Marko,

> why PCP wants to access several files under home directories

pmdaproc issues setresuid(2), setresgid(2) to change accounts to (temporarily) become the user running the client tool, for the duration of the /proc sampling (so, accessing these files may be implicit - certainly nothing in PCP that is doing that explicitly).

From a quick look at the code, it reports zero values when no values can be successfully extracted for the proc.io.* metrics.

cheers.

(In reply to Marko Myllynen from comment #2)
> why PCP wants to access several files under users' home directories?

This is due to src/pmdas/linux_proc/getinfo.c:

     22 char *
     23 get_ttyname_info(int pid, dev_t dev, char *ttyname)
     24 {
[...]
     37             sprintf(procpath, "/proc/%d/fd/%s", pid, dp->d_name);
     38             if (realpath(procpath, ttypath) == NULL || stat(ttypath, &sbuf) < 0)
     39                 continue;

and realpath() involves considerable readlink and filesystem traversal, repeated over multiple file descriptors, per process.

i.e., it's for satisfying the "proc.psinfo.ttyname" metric.

(In reply to Frank Ch. Eigler from comment #4)
> (In reply to Marko Myllynen from comment #2)
> > why PCP wants to access several files under users' home directories?
> 
> This is due to src/pmdas/linux_proc/getinfo.c:
> 
>      22 char *
>      23 get_ttyname_info(int pid, dev_t dev, char *ttyname)
>      24 {
> [...]
>      37             sprintf(procpath, "/proc/%d/fd/%s", pid, dp->d_name);
>      38             if (realpath(procpath, ttypath) == NULL || stat(ttypath,
> &sbuf) < 0)
>      39                 continue;
> 
> and realpath() involves considerable readlink and filesystem traversal,
> repeated over multiple file descriptors, per process.

Good catch - fetching everything under proc except for proc.psinfo.ttyname does not generate anymore AVCs expect for the occasional:

type=AVC msg=audit(1463387051.279:513): avc:  denied  { sys_ptrace } for  pid=1708 comm="pmdaproc" capability=19  scontext=system_u:system_r:pcp_pmcd_t:s0 tcontext=system_u:system_r:pcp_pmcd_t:s0 tclass=capability
type=SYSCALL msg=audit(1463387051.279:513): arch=c000003e syscall=89 success=yes exit=9 a0=7ffd3a5f4c20 a1=7ffd3a5f2a70 a2=fff a3=1 items=0 ppid=1702 pid=1708 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pmdaproc" exe="/var/lib/pcp/pmdas/proc/pmdaproc" subj=system_u:system_r:pcp_pmcd_t:s0 key=(null)

It would seem that the most reliable way here to reproduce is to restart pmcd and then do pminfo -f proc.io or pminfo -f proc.memory. (Didn't get any hints when ran stap -e 'probe syscall.ptrace { print_ubacktrace() }' when testing.)

Thanks.

And these pop up when the month changes:

type=AVC msg=audit(1464729011.915:575): avc:  denied  { read } for  pid=1784 comm="pmcd" name="pmlogger_daily.pid" dev="tmpfs" ino=78123 scontext=system_u:system_r:pcp_pmcd_t:s0 tcontext=system_u:object_r:cron_var_run_t:s0 tclass=file

type=AVC msg=audit(1464729011.914:574): avc:  denied  { create } for  pid=11763 comm="pmlogger" name="pmlogger.primary.socket" scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=lnk_file

type=AVC msg=audit(1464729011.888:573): avc:  denied  { execute } for  pid=11765 comm="sh" name="pmcpp" dev="dm-1" ino=538657541 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file

type=AVC msg=audit(1464729011.888:572): avc:  denied  { getattr } for  pid=11765 comm="sh" path="/proc/meminfo" dev="proc" ino=4026532039 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1464729011.888:572): arch=x86_64 syscall=fstat success=yes exit=0 a0=3 a1=7ffd13df5490 a2=7ffd13df5490 a3=0 items=0 ppid=11763 pid=11765 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=sh exe=/usr/bin/bash subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1464729011.888:571): avc:  denied  { read } for  pid=11765 comm="sh" name="meminfo" dev="proc" ino=4026532039 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=AVC msg=audit(1464729011.888:571): avc:  denied  { open } for  pid=11765 comm="sh" path="/proc/meminfo" dev="proc" ino=4026532039 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1464729011.888:571): arch=x86_64 syscall=open success=yes exit=ESRCH a0=7fbbdd47d3c9 a1=80000 a2=1b6 a3=24 items=0 ppid=11763 pid=11765 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=sh exe=/usr/bin/bash subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1464729011.887:570): avc:  denied  { execute } for  pid=11765 comm="pmlogger" name="bash" dev="dm-1" ino=271724700 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=AVC msg=audit(1464729011.887:570): avc:  denied  { execute_no_trans } for  pid=11765 comm="pmlogger" path="/usr/bin/bash" dev="dm-1" ino=271724700 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1464729011.887:570): arch=x86_64 syscall=execve success=yes exit=0 a0=7ff8f84e3de9 a1=7fffcc484300 a2=7fffcc489790 a3=7ff8f8dbaa10 items=0 ppid=11763 pid=11765 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=sh exe=/usr/bin/bash subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1464729011.886:569): avc:  denied  { ioctl } for  pid=11763 comm="pmlogger" path="socket:[79160]" dev="sockfs" ino=79160 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1464729011.886:569): arch=x86_64 syscall=ioctl success=yes exit=0 a0=7 a1=8933 a2=7fffcc483cc0 a3=3 items=0 ppid=11617 pid=11763 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=pmlogger exe=/usr/bin/pmlogger subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1464729011.886:568): avc:  denied  { create } for  pid=11763 comm="pmlogger" scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1464729011.886:568): arch=x86_64 syscall=socket success=yes exit=E2BIG a0=1 a1=80002 a2=0 a3=3 items=0 ppid=11617 pid=11763 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=pmlogger exe=/usr/bin/pmlogger subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

type=AVC msg=audit(1464729011.886:567): avc:  denied  { read } for  pid=11763 comm="pmlogger" name="unix" dev="proc" ino=4026532014 scontext=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_net_t:s0 tclass=file
type=SYSCALL msg=audit(1464729011.886:567): arch=x86_64 syscall=access success=yes exit=0 a0=7fffcc483c60 a1=4 a2=7fffcc483c6e a3=3 items=0 ppid=11617 pid=11763 auid=991 uid=991 gid=989 euid=991 suid=991 fsuid=991 egid=989 sgid=989 fsgid=989 tty=(none) ses=24 comm=pmlogger exe=/usr/bin/pmlogger subj=system_u:system_r:pcp_pmlogger_t:s0-s0:c0.c1023 key=(null)

Thanks.

(In reply to Marko Myllynen from comment #5)
> [...] 
>  - fetching everything under proc except for proc.psinfo.ttyname
> does not generate anymore AVCs expect for the occasional:

I've rewritten the PCP code behind the proc.psinfo.ttyname metric now, and confirmed it no longer generates AVCs, so that's one down at least.

cheers.

pmval does not produce AVCs when run on thunderbird (as described in reproducer) but when run on all processes there are still AVCs.

Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-97.el7.noarch
pcp-3.11.3-4.el7.x86_64

Actual results:
# pmval -r -s 1 proc.io.read_bytes
...
# ausearch -m avc
----
time->Wed Sep  7 05:47:29 2016
type=SYSCALL msg=audit(1473241649.586:975): arch=c000003e syscall=0 success=no exit=-13 a0=6 a1=7fffe3da6320 a2=400 a3=2 items=0 ppid=2675 pid=2676 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pmdaproc" exe="/var/lib/pcp/pmdas/proc/pmdaproc" subj=system_u:system_r:pcp_pmcd_t:s0 key=(null)
type=AVC msg=audit(1473241649.586:975): avc:  denied  { sys_ptrace } for  pid=2676 comm="pmdaproc" capability=19  scontext=system_u:system_r:pcp_pmcd_t:s0 tcontext=system_u:system_r:pcp_pmcd_t:s0 tclass=capability
...
(repeats many times)
# ausearch -m avc | audit2allow
#============= pcp_pmcd_t ==============
allow pcp_pmcd_t self:capability sys_ptrace;

Beat, 
If you want to have it fixed in RHEL-7.3.z, please attach business justification and set rhel-7.3.z flag to '?'. 

From my POV, I'm fine with fix.

(In reply to Marko Myllynen from comment #6)
> And these pop up when the month changes:
> 
> type=AVC msg=audit(1464729011.915:575): avc:  denied  { read } for  pid=1784
> comm="pmcd" name="pmlogger_daily.pid" dev="tmpfs" ino=78123
> scontext=system_u:system_r:pcp_pmcd_t:s0
> tcontext=system_u:object_r:cron_var_run_t:s0 tclass=file

If the pcp-pmlogger cronjob script is executed by crond then it runs under following SELinux context:

Apr 05 08:16:01 qeos-133.lab.eng.rdu2.redhat.com pcp[17458]: system_u:system_r:system_cronjob_t:s0-s0:c0.c1023

1) If /var/run/pcp directory exists and has correct UNIX permissions and correct SELinux label (pcp_var_run_t), then pcp-pmlogger cronjob creates its PID file in /var/run/pcp directory and the file inherits its SELinux label from the directory, which is expected.

Apr 05 08:16:01 qeos-133.lab.eng.rdu2.redhat.com pcp[17497]: -rw-r--r--. pcp pcp system_u:object_r:pcp_var_run_t:s0 /var/run/pcp/pmlogger_daily.pid

2) If /var/run/pcp directory does not exist, then pcp-pmlogger cronjob script is not enable to create the directory because the script runs under pcp user and:

# ls -ld /var/run/
drwxr-xr-x. 29 root root 920 Apr  5 08:28 /var/run/
#

3) If /var/run/pcp directory exists, has correct UNIX permissions, but incorrect SELinux label (var_run_t) then pcp-pmlogger cronjob creates its PID file with incorrect SELinux label:

# matchpathcon /var/run/
/var/run	system_u:object_r:var_run_t:s0
# sesearch -s system_cronjob_t -t var_run_t -T
Found 1 semantic te rules:
   type_transition system_cronjob_t var_run_t : file cron_var_run_t; 

#

and the above-mentioned AVC appears as a consequence.

(In reply to Milos Malik from comment #27)

This should be fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1381301

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://access.redhat.com/errata/RHBA-2017:1861