| 1 |
On 11/26/20 10:07 AM, Thomas Deutschmann wrote: |
| 2 |
> |
| 3 |
> Only root is allowed to write to these directories. In other words: To |
| 4 |
> exploit this, a malicious local user (or a remote attacker who already |
| 5 |
> gained user access) would have to trick root into creating specially |
| 6 |
> crafted tmpfiles config allowing for race conditions first (according to |
| 7 |
> the 10 immutable laws of security, if this is already possible, you are |
| 8 |
> already lost). |
| 9 |
|
| 10 |
Most of these security issues were fixed in systemd-tmpfiles years ago, |
| 11 |
and you can easily find upstream tmpfiles.d entries that contain e.g. |
| 12 |
"Z" entries. In that case, the upstream file is not in error, and root |
| 13 |
doesn't have to be actively tricked into installing anything -- it will |
| 14 |
just happen. |
| 15 |
|
| 16 |
Opentmpfiles literally cannot fix this. There is no POSIX API to safely |
| 17 |
handle hardlinks. At best it can be reduced to the same race condition |
| 18 |
we have in checkpath, but the entire project would have to be rewritten |
| 19 |
in C to accomplish even that. |
| 20 |
|
| 21 |
Corollary: the tmpfiles.d specification can only be implemented (safely) |
| 22 |
on Linux after all. |
Archives