Local root vulnerability in snap-confine [LWN.net]

Local root vulnerability in snap-confine

Posted Feb 18, 2022 8:59 UTC (Fri) by epa (subscriber, #39769)
In reply to: Local root vulnerability in snap-confine by jra
Parent article: Local root vulnerability in snap-confine

Would it be fair to say that most of these security holes are not caused by symlinks alone, but by race conditions with symlinks?

The legitimate uses of symlinks are mostly static -- a shared library linked to a different name, an old user who no longer exists. They don't change much. Can we somehow restrict the times at which symbolic links can be created or changed? Perhaps a process should only be able to see the symlinks that existed when that process started, unless it calls a refresh_symlinks() system call. That would avoid path traversal race conditions while still letting us have the uses of symlinks we've come to depend on.

to post comments

Local root vulnerability in snap-confine

Posted Feb 18, 2022 11:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (4 responses)

That is a lot of state that needs to be tracked. It also raises the question of "how do I debug this path (name) not resolving in this daemon" with fun "oh, it hasn't updated its symlink view" kinds of answers.

Local root vulnerability in snap-confine

Posted Feb 18, 2022 12:46 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

Maybe if a symbolic link has appeared or changed since you last called refresh(), then path lookup operations traversing that link would fail with EREFRESH. This would be fail-safe for older code, and newer code might be able to handle it sanely (it certainly sounds easier than meticulously rewriting all your code with the 'at' system calls). At worst, you just have to restart your daemon. Again, symlinks don't change often in practice so this doesn't seem too high a price.

It would have to be based on real world time, not just whatever mtime is in the file system. A fully snapshottable filesystem would be impossible to graft on to current POSIX semantics, but if we're just making a sticking plaster for race conditions with symlinks, some kind of per-process view of the world seems possible. You're not trying to snapshot exactly what symlinks existed at a point of time, but only to note whether one has changed in any way, and if so fail when it's used.

Local root vulnerability in snap-confine

Posted Feb 18, 2022 14:57 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

Yup. Don't snapshot your symlinks per process, but make it so the first access caches it - REMEMBERING THE INODE - and any further attempts to access the symlink get the same inode until the cache is actively flushed.

Cheers,
Wol

Local root vulnerability in snap-confine

Posted Feb 18, 2022 20:50 UTC (Fri) by developer122 (guest, #152928) [Link]

A surprisingly elegant solution, imo.

Local root vulnerability in snap-confine

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

> This would be fail-safe for older code

What? It would cause new failures for older code, i.e. it would introduce countless DoS vectors, only a microscopic proportion of which correspond to actual attacks, but all of which would annoy users (where "annoy users" spans the entire spectrum from "slightly annoying" through "bug we can't track down that goes away on restarting" through to "oops now the system is unbootable because of an unexpected and undiagnosed EREFRESH while installing something boot-critical").

Hell no.

"owning" a symlink?

Posted Feb 21, 2022 10:14 UTC (Mon) by kronat (guest, #117266) [Link]

> The legitimate uses of symlinks are mostly static [...]
Based on the above, isn't it possible to "block" any modification to the symlink until the application(s) that "locked" the symlink by opening it for reading is (are) done (doing a close on it)?