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

Posted Feb 18, 2022 17:46 UTC (Fri) by nybble41 (subscriber, #55106)
In reply to: The long road to a fix for CVE-2021-20316 by pmatilai
Parent article: The long road to a fix for CVE-2021-20316

> [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.