The long road to a fix for CVE-2021-20316

Posted Feb 16, 2022 8:59 UTC (Wed) by pmatilai (subscriber, #15420)
In reply to: The long road to a fix for CVE-2021-20316 by nix
Parent article: The long road to a fix for CVE-2021-20316

Yup, that is exactly the approach rpm started taking internally since 2017: https://github.com/rpm-software-management/rpm/commit/f2d...
I've yet to see it break any legitimate case in the packaging world.

That commit is of course only a tiny fraction (and buggy at that) of the overall problem which we're only just now getting close to resolving it in a wider sense - much like Samba, rpm traditionally used absolute paths for everything.

The long road to a fix for CVE-2021-20316

Posted Feb 18, 2022 1:50 UTC (Fri) by nix (subscriber, #2304) [Link]

Aha! I see there are no new ideas, only ideas someone else already implemented, better :) The 'target directory owner' idea is a nice addition, which could probably be added in to what I thought up above to close even more cases where legitimate use might be broken without enabling any troublesome cases at all.

The long road to a fix for CVE-2021-20316

Posted Feb 18, 2022 17:46 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> [from the linked commit] The rationale is that if you can create symlinks owned by user X you *are* user X (or root), and if you also own directory Y you can do whatever with it already, including change permissions.

This is a false assumption. The owner of a file or directory can only change permissions or make other changes to it *if they can obtain a reference*. If you own /a/b but don't have search permissions (+x) on /a (and don't have /a/b as your current directory or some similar corner case) then you can't do anything with /a/b. However, under this rule you can still create a symlink to /a/b which would be followed by other users because you own /a/b, even though you can't access it yourself through /a. (The same issue impacts /proc/sys/fs/protected_symlinks=1.)

One option I haven't seen suggested yet would be to use the intersection of the permissions available to the original user and the owner(s) of any symlink(s) followed while resolving the path. Though in practice you might need more information than just the symlink's UID and GID to serve as the credentials, especially when relying on "negative ACLs", pluggable security modules like SELinux, or narrower group permissions overriding, rather than supplementing, broader "other" permissions.