ds-identify doesn't play nice with SELinux

[ajorg]

Bug report

Because ds-identify uses exec to redirect output for logging to /run/cloud-init/ds-identify.log, any tools it uses need permission to write to that log. dmidecode is one of those tools, and it definitely wouldn't make sense for it to have write permissions. So when SELinux is in enforcing mode, depending on the policy applied, of course, the script can fail.

[   33.715144] audit: type=1400 audit(1714589839.180:50): avc:  denied  { append } for  pid=5932 comm="dmidecode" path="/run/cloud-init/ds-identify.log" dev="tmpfs" ino=1207 scontext=system_u:system_r:dmidecode_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive=0

Steps to reproduce the problem

The steps should be to enabled selinux enforcing and watch ds-identify fail. But I'm not actually certain if the customer who reported this had a stricter policy than would normally be used for dmidecode. They used RHEL 8, but I expect this to fail on other hosts with SELinux (or apparmor).

Environment details

• Cloud-init version: Not sure, but the code is the same in mainline
• Operating System Distribution: RHEL 8
• Cloud provider, platform or installer type: GCP

cloud-init logs

I don't have these from the customer's report, and I'm not sure they'd include the ds-identify logs since it's an independent script.

I'll see if I can't find some time to configure RHEL 8 + cloud-init + selinux enforcing if needed, but the problem seems fairly plain to me. I'd heard rumors that using exec for logging can have unexpected consequences, but this one was a surprise to me.

[holmanb]

@ajorg Thanks for the report!

Because ds-identify uses exec to redirect output for logging to /run/cloud-init/ds-identify.log, any tools it uses need permission to write to that log.

I wouldn't have expected that.

but I expect this to fail on other hosts with SELinux (or apparmor).

cloud-init is pretty thoroughly tested on Ubuntu, so I wouldn't assume this issue to affect users of apparmor

I'll see if I can't find some time to configure RHEL 8 + cloud-init + selinux enforcing if needed, but the problem seems fairly plain to me. I'd heard rumors that using exec for logging can have unexpected consequences, but this one was a surprise to me.

I just enabled selinux in enforcing mode on a Fedora 40 VM and ran ds-identify and I wasn't able to reproduce the issue. Could you please include either logs or a reproducer to dig into?

[ajorg]

Yep, I'll try to see if I can repro on RHEL 8. It's a strange result.