Bug 1664651

I can see the problem with the newest sosreport version, but rather suspect systemd-tmpfiles to misbehave. Reproducer on any RHEL8:

1) Edit /usr/lib/systemd/system/systemd-tmpfiles-clean.timer :

[Timer]
OnBootSec=5min
OnUnitActiveSec=1min


2) reload that config:

systemctl daemon-reload


3) generate those files by generating unpacked sosreport (comes from sos package, if missing):

sosreport -o pam,system --batch --build
..
sosreport build tree is located at : /var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn


4) Wait a minute and run:

tail -f /var/log/audit/audit.log | grep AVC
..
type=AVC msg=audit(1547070691.661:259): avc:  denied  { getattr } for  pid=4153 comm="systemd-tmpfile" path="/var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/etc/security/opasswd" dev="dm-0" ino=12968702 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file permissive=0
type=AVC msg=audit(1547070691.661:260): avc:  denied  { getattr } for  pid=4153 comm="systemd-tmpfile" path="/var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/proc/sys/vm/compact_memory" dev="dm-0" ino=9002675 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=file permissive=0

will appear every minute.


Explanation: Sosreport collects various stuff including whole /proc/sys/vm (imho redundant to collect) and also /etc/security/opasswd (brief check shows also redundant?). And copies permissions incl.SELinux context, so we can see:

# ll -Z /var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/etc/security/opasswd /var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/proc/sys/vm/compact_memory
-rw-------. 1 root root system_u:object_r:shadow_t:s0    0 Sep 10 15:42 /var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/etc/security/opasswd
--w-------. 1 root root system_u:object_r:sysctl_vm_t:s0 0 Jan  9 21:43 /var/tmp/sosreport-pmoravec-rhel8-2019-01-09-qkwdjdn/proc/sys/vm/compact_memory
#

That makes problems for that cleanup service running "/usr/bin/systemd-tmpfiles --clean" in this SELinux context:

system_u:system_r:systemd_tmpfiles_t:s0 root 12685 0.0  0.4 101152 8932 ?      Rs   21:54   0:00 /usr/bin/systemd-tmpfiles --clean

Apparently the SELinux policy does not allow that process in context system_u:system_r:systemd_tmpfiles_t:s0 to delete files in context system_u:object_r:shadow_t:s0 or system_u:object_r:sysctl_vm_t:s0 .


This is more generic problem: one can put to tmp directories *any* content of *any* context. Shall systemd-tmpfiles delete everything? (but if so, won't it be too error-prone to tmpfiles.d mis-config, either by a mistake or by an attack of an intruder?)?

Imho systemd-tmpfiles should resolve this generic problem, reassigning there.

Bryn,
do you see some rationale in sosreport collecting either of:

/etc/security/opasswd  (I thought it is historic relict, but pam_unix uses it - can't it contain some useful data?)

/proc/sys/vm  (afaik all files there stand for updating configuration of the VM only, nothing to collect from there)

?

Well this is definitelly not a bug in systemd code base. Tmpfiles is trying to clean up the /var/tmp but it can't touch some files that were copied there with their original selinux labels, so either sos report should ship a drop-in telling the tmpfiles to skip those directories or we need a change in selinux policy.

(In reply to Lukáš Nykrýn from comment #4)
> Well this is definitelly not a bug in systemd code base. Tmpfiles is trying
> to clean up the /var/tmp but it can't touch some files that were copied
> there with their original selinux labels, so either sos report should ship a
> drop-in telling the tmpfiles to skip those directories or we need a change
> in selinux policy.

So an application or user is responsible for storing files with "unacceptable" SELinux context under /var/tmp, that makes also sense. I see three possible ways of a fix:

- dont collect the two problematic files with a SELinux context problematic to systemd-tmpfiles - but sosreport might collect similar files in future, it is better to provide a solid / general resolution than this

- sosreport to tell systemd-tmpfiles what directories to skip - what command (ideally in python) can do tell "skip directory /var/tmp/blah"?

- or the systemd-tmpfiles to allow reading (and also deleting?) the two problematic SELinux file contexts - but again, as sosreport is evolving over time, we might need some other rule in future - better the 2nd option


As a systemd newbie, am I right this is the correct approach?
- I need to tell systemd to ignore directories+files /var/tmp/sos\.[a-z0-9]{8} and /var/tmp/sosreport*
- doing so, it is sufficient to in advance (i.e. when installing sosreport from a package) create file:

/etc/tmpfiles.d/sosreport.conf

with content:

x /var/tmp/sos\.[a-z0-9]{8}
x /var/tmp/sosreport*

and no service restart or reload is needed?


(I would expect so, but this fails on the /var/tmp/sos\.[a-z0-9]{8} :

mkdir /var/tmp/sos.sy7rqkf2
cp -a /proc/sys/vm/compact_memory /var/tmp/sos.sy7rqkf2

and this still generates AVCs on the /var/tmp/sos.sy7rqkf2/compact_memory file)

Using there sos\..{8} does not help either. What am I doing wrong with the exclude regexp, please?

Re=iterating the needinfo. Without that I am blocked with a fix.

(In reply to Pavel Moravec from comment #6)
> Re=iterating the needinfo. Without that I am blocked with a fix.

Last call for passen.. eh, for needinfo, before the BZ will be closed.

Please provide the requested needinfo, or the BZ will be closed in 2 months.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

I am reopening the bugzilla since the issue is still present and sometimes breaks some tests with sos (and can lead to a real "issue" on customer systems).

We should deliver sos with a /etc/tmpfiles.d/sos.conf file (if that dir exists) to prevent the AVCs. Just I dont know the file syntax..

Hello,
this bug is assumed to be fixed in errata https://access.redhat.com/errata/RHBA-2023:3801 so I am closing this BZ as fixed in current release.

If you feel otherwise, please reopen the BZ and provide details what is missing.