Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

[Thomas Deutschmann <whissi@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2092 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]