SELinux question related to setting up tmpfiles.d on CrOS

[Allen Webb]

I am setting up tmpfiles.d on Chrome OS and I was trying to figure out what to do about some error messages it prints when trying to set up the directory structure. I have included the errors below:

Failed to determine SELinux security context for /run/rsyslogd: Resource temporarily unavailable
Failed to create directory or subvolume "/run/rsyslogd": Resource temporarily unavailable
Failed to determine SELinux security context for /var/log/bluetooth.log: Resource temporarily unavailable
Unable to fix SELinux security context of /var/log/bluetooth.log (/var/log/bluetooth.log): Resource temporarily unavailable

I get the errors when running:

runcon u:r:cros_init_scripts:s0 systemd-tmpfiles --create --remove /usr/lib/tmpfiles.d/syslog.conf

When I run "ls -ldZ /run/rsyslogd", I get:

drwxr-xr-x. 2 root root u:object_r:cros_run_rsyslogd:s0 60 Dec  2 20:49 /run/rsyslogd

So clearly there is a context for the path.

Any suggestions?

Allen

[Mike Frysinger]

maybe the dirs are bind mounted and the kernel doesn't like that? and the log files are opened by another process?

can you look at fuser/lsof?

-mike

[Allen Webb]

It turns out the labels were there because of the domain that created the files, so they were indeed missing from the sepolicy.

[Allen Webb]

Why don't we run restorecon after "cros deploy ... selinux-policy" to fix the labels for the root-fs?

"cros deploy" already remounts the root-fs read-write. I could see some possibility of differences in how restorecon would behave and how the labels would be applied to the rootfs when building an image, but I was able to test changes I made using restorecon with some success.

[Mike Frysinger]

mmm we do run restorecon in cros deploy in general, but only for the files we just deployed.  we don't have special logic for the policy files.  does that even work ?  last i looked, i thought some things (like ARC?) compiled stuff while creating the image which means updating the polices on the fly wouldn't work.  Qijiang should be able to clarify/correct my understanding ...

-mike

[Allen Webb]

I ended up filing a feature request at https://crbug.com/1157288 in case we can improve the workflow, so it probably makes sense to continue there.

[Qijiang Yūki Ishii]

Hi,

// Resend the same email after joining groups since the previous one is rejected by the group.

As Mike mentioned, we only do restorecon for deployed files (otherwise it inherits its parent, and all xxxx_exec is lost for executables).

Fixing root-fs is not possible as I'm aware using restorecon after redeploying selinux-policy. restorecon doesn't read your policy or file_contexts in /etc/selinux, but uses current-loaded ones. Until you reboot, and init reloads new policy, restorecon wouldn't take it.

It might be helpful to use setfiles, but it still will only work if you rename some files, not adding new types. since the xattr value you set will only be interpreted as invalid security context and fallback to unlabeled by the kernel without reloading the binary policy with a reboot.

I think we have printed a notice to ask developers to reboot the DUT after deploying selinux-policy package.

Regards,

--

Qijiang Fan |

Software Engineer |

f...@google.com |

+81-3-6384-9927

このメールには機密事項が記載されている可能性があります。このメールが間違って送信されたと思われる場合は、すぐにお問い合わせください。いかなる理由でもコピーしたり、第三者にコンテンツを公開しないでください。インターネットでのコミュニケーションはセキュリティが保護されておらず、このメッセージは公共のネットワークを通して送信されているため、Google でそのコンテンツに対する法的責任を負うことはいたしかねます。メッセージが第三者に傍受された、または改ざんされたと思われる場合、Google までお問い合わせください。

If you received this communication by mistake, please don't forward it to anyone else (it may contain confidential or privileged information), please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thanks.