On 2020-11-26 21:36, Michael Orlitzky wrote:
Most of these security issues were fixed in systemd-tmpfiles years ago, and you can easily find upstream tmpfiles.d entries that contain e.g. "Z" entries. In that case, the upstream file is not in error, and root doesn't have to be actively tricked into installing anything -- it will just happen.
I disagree here: Packages installing tmpfiles configs requiring recursive chown on each boot are doing something wrong from my P.O.V. like you can never safely do that (you can only take precaution like not following symlinks but in this case you don't do what you were asked to do so you shouldn't return 'Yup, I chowned everything like you asked me to do').
Opentmpfiles literally cannot fix this. There is no POSIX API to safely handle hardlinks. At best it can be reduced to the same race condition we have in checkpath, but the entire project would have to be rewritten in C to accomplish even that.
Note that hardlinks aren't even fixed for systemd's tmpfiles provider. It will always rely on fs.protected_hardlinks for example. And checking for hardlinks like happened to address CVE-2017-18078 will create another TOCTOU race. Where is the follow-up report for this?
In short: As long as it is possible for attacker to write to directory you are working on you can never do mentioned things in a safe way. You first have to revoke access for everyone except you and then you can start checking file per file... but *no* implementation is doing something like that.
And keep in mind: We are talking about an attack vector where we already assume someone successfully compromised an application and can now do everything the application user can do for which we do the work in tmpfiles config. Saying that systemd's implementation is more secure than OpenTmpfiles' implementation when you are still able to escalate privileges is very misleading.
-- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Description: OpenPGP digital signature