Created attachment 1907432 [details]
AVC events for insights_client_t

I'm seeing the attached AVC denials with selinux-policy-3.14.3-95.el8_6.4.noarch

Thank you for the ausearch command output. I see these groups of issues:
- get attributes of various processes and their open files
- lock files usage
- additional permissions to read files or use sockets
- write to config_home_t
- setrlimit permissions
- communication with containers
- grafana.process

First three should be addressed by this bz.
For another three we need to know the configuration changes to trigger these denials, and/or have audit logs with full auditing enabled. In particular, based on experience setrlimit often appears on a system with high load, but some data are needed to actually assess.
The last one is a domain not provided by Red Hat selinux-policy.

Thanks for taking a look at the log. I can re-run insights-client & provide the full audit.log & insights-client.log, contents of /etc/insights-client if that's helpful? But I haven't customized insights-client at all so all these denials are I presume from insights-client trying to do whatever it does by default. :)

> write to config_home_t

Per the proctitle lines, these are from insights-client running "fwupdagent get-devices" and "fwupdagent security --force" - I guess they try to write to somewhere under /root/.config.

> setrlimit permissions

These are from insights-client running podman ps, podman images, etc. I take the point about the system being under load, I recall a KCS about similar messages being generated when the system is short of memory(?)

> communication with containers

Is this insights-client running lsof on processes running inside containers?

> grafana.process

This domain is generated by udica (I can provide the .cil file you want). I think if insights_client is expected to be able to run, it looks like lsof?, on processes inside containers started with podman [which use the default container_t domain], then it should be able to do the same on processes inside containers that use udica-generated domains, which inherit from the default container/net_container blocks? OTOH I'm fine ignoring this one--but I expect you'll see other similar reports from people running insights-client on machines where they use udica-generated policies for their containers.

Maybe what insights-client is doing to the container_t & grafana.process processes is covered already by "get attributes of various processes and their open files"? In which case, ignoring the setrlimit permissions, the only oversight in selinux policy is allowing insights-client to correctly run fwupdagent.

(In reply to Milos Malik from comment #24)
> The following SELinux denials appeared on a clean ppc64le machine
> (RHEL-8.7.0-20220831.0 compose):
> ----
> type=PROCTITLE msg=audit(08/31/2022 15:45:57.579:484) :
> proctitle=/usr/bin/lscpu 
> type=PATH msg=audit(08/31/2022 15:45:57.579:484) : item=1
> name=/var/lock/LCK..librtas inode=14295 dev=00:18 mode=file,600 ouid=root
> ogid=root rdev=00:00 obj=system_u:object_r:rtas_errd_var_lock_t:s0
> nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
> type=PATH msg=audit(08/31/2022 15:45:57.579:484) : item=0 name=/var/lock/
> inode=1078 dev=00:18 mode=dir,755 ouid=root ogid=root rdev=00:00
> obj=system_u:object_r:var_lock_t:s0 nametype=PARENT cap_fp=none cap_fi=none
> cap_fe=0 cap_fver=0 cap_frootid=0 
> type=CWD msg=audit(08/31/2022 15:45:57.579:484) : cwd=/ 
> type=SYSCALL msg=audit(08/31/2022 15:45:57.579:484) : arch=ppc64le
> syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD
> a1=0x7fffa6977728 a2=O_RDWR|O_CREAT a3=0x180 items=2 ppid=32998 pid=32999
> auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root
> sgid=root fsgid=root tty=(none) ses=unset comm=lscpu exe=/usr/bin/lscpu
> subj=system_u:system_r:insights_client_t:s0 key=(null) 
> type=AVC msg=audit(08/31/2022 15:45:57.579:484) : avc:  denied  { write }
> for  pid=32999 comm=lscpu name=LCK..librtas dev="tmpfs" ino=14295
> scontext=system_u:system_r:insights_client_t:s0
> tcontext=system_u:object_r:rtas_errd_var_lock_t:s0 tclass=file permissive=0 
> ----
> type=PROCTITLE msg=audit(08/31/2022 15:51:43.266:599) :
> proctitle=/usr/bin/lscpu 
> type=PATH msg=audit(08/31/2022 15:51:43.266:599) : item=0 name=/dev/mem
> inode=3074 dev=00:06 mode=character,640 ouid=root ogid=kmem rdev=01:01
> obj=system_u:object_r:memory_device_t:s0 nametype=NORMAL cap_fp=none
> cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
> type=CWD msg=audit(08/31/2022 15:51:43.266:599) : cwd=/ 
> type=SYSCALL msg=audit(08/31/2022 15:51:43.266:599) : arch=ppc64le
> syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD
> a1=0x7fffa5c87660 a2=O_RDWR a3=0x0 items=1 ppid=34670 pid=34671 auid=unset
> uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
> fsgid=root tty=(none) ses=unset comm=lscpu exe=/usr/bin/lscpu
> subj=system_u:system_r:insights_client_t:s0 key=(null) 
> type=AVC msg=audit(08/31/2022 15:51:43.266:599) : avc:  denied  { read write
> } for  pid=34671 comm=lscpu name=mem dev="devtmpfs" ino=3074
> scontext=system_u:system_r:insights_client_t:s0
> tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0 
> ----

Karle,

lscpu requests to read/write /dev/mem and write to /run/lock/LCK..librtas. It seems to trigger only on ppc64le.

Is this expected? Is it required for lscpu to work properly, or can we dontaudit (silence) the reported AVC denials?

*** Bug 2131733 has been marked as a duplicate of this bug. ***

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 (selinux-policy bug fix and enhancement update), 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-2022:7691

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days