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

Posted Feb 14, 2022 8:07 UTC (Mon) by eru (subscriber, #2753)
In reply to: The long road to a fix for CVE-2021-20316 by metalheart
Parent article: The long road to a fix for CVE-2021-20316

Symlinks may be problematic, but IMHO they are also one of the killer features Linux (and relatives) have over that other OS.

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

Posted Feb 14, 2022 17:32 UTC (Mon) by jra (subscriber, #55261) [Link] (5 responses)

No, they aren't anymore. Windows has admin-only created symlinks. The key difference is only root can create them.

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

Posted Feb 15, 2022 12:18 UTC (Tue) by eru (subscriber, #2753) [Link] (1 responses)

The Windows symlink-like feature is hard to use, and last I tried it, it was nearly undocumented (admittedly that was several years ago when I needed it). On the Windows command line, there was no equivalent to "ln -s". They might as well not exist, for all the good they do there. Maybe Windows uses them internally for something, but no end-user does.

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

Posted Feb 15, 2022 14:09 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> On the Windows command line, there was no equivalent to "ln -s". They might as well not exist, for all the good they do there. Maybe Windows uses them internally for something, but no end-user does.

Your info is heavily outdated. It is well supported and well documented these days.

https://docs.microsoft.com/en-us/windows-server/administr...

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

Posted Feb 19, 2022 17:10 UTC (Sat) by Jandar (subscriber, #85683) [Link] (2 responses)

> Windows has admin-only created symlinks.

Marvelous, a kind of symlink a user can't use. What comes next, only admin approved (*) programs can create executables? Doubtless it would be a security enhancement if no executable memory-mapping could contain bytes generated by an arbitrary program.

Most symlinks I use or encounter are made by users within their own directories pointing into other parts of their own space.

* The mainframe I used at university had such a concept. IIRC only an admin at the console could set the compiler-permission.

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

Posted Feb 21, 2022 0:38 UTC (Mon) by Fowl (subscriber, #65667) [Link] (1 responses)

Well, yeah. This is how many corporate managed devices, and all iOS and Android devices work.

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

Posted Feb 22, 2022 16:56 UTC (Tue) by Jandar (subscriber, #85683) [Link]

> This is how many corporate managed devices, and all iOS and Android devices work.

And this is why an Android device even with a Linux kernel doesn't provide a very Unix like experience.

If my desktop, laptop or servers would restrict me in the same way as an Android device I would immediately switch the distribution or to something more different like one of the BSDs.

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

Posted Feb 15, 2022 16:07 UTC (Tue) by Wol (subscriber, #4433) [Link] (12 responses)

> they are also one of the killer features

What's so "killer feature" about them?

Coming from OSs that didn't have symlinks, I don't use them. I do make use of hard links, mostly to provide multiple links to semi-archive material (and also to protect against accidental deletion, which symlinks don't). So what ARE the advantages?

Cheers,
Wol

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

Posted Feb 15, 2022 17:44 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (11 responses)

> So what ARE the advantages?

* You can symlink across filesystems, but hard links only work within filesystems.

* If a file is deleted and replaced (i.e. the ubiquitous "atomic rename" pattern) this breaks hard links, but not symlinks.

* Symlinks can point to directories, while hard links to directories are either disallowed altogether or heavily restricted.

* Symlinks interact better with filesystem quotas. If you can create a hard link to a file owned by another user in a location they can't access, and the original path is later deleted, then you can cause that part of their quota to be permanently inaccessible to them. (Alternatively, the system can disallow hard links to other user's files—in which case the advantage of symlinks is not having this restriction.)

* You can read a symlink to determine where it goes, but with hard links you only have an inode number.

* Directory entries accessed through symlinks have canonical paths, but hard-linked inodes have multiple, equally authoritative, paths.

> Coming from OSs that didn't have symlinks, I don't use them.

Which OS do you use that doesn't have symlinks? Not Linux, or MacOS, or Windows… though symlinks in Windows are a bit different, it does have them. You create them with the "mklink" command. They aren't strictly limited to administrator accounts either; that's just a default setting. The biggest difference is that Windows distinguishes between symlinks to files and symlinks to directories. It also has "junction points" which work much like symlinks (but only for directories). Also let's not forget "shortcuts" (*.lnk files), which are basically symlinks implemented somewhat inconsistently at a layer above the kernel. These have been around since Windows ran under DOS.

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

Posted Feb 15, 2022 19:24 UTC (Tue) by jra (subscriber, #55261) [Link] (2 responses)

Symlinks are seductive. They provide all the benefits you enumerate, but at the cost of completely destroying application security when working with pathnames. They took the beautiful POSIX API of a directory tree structure and turned it into a graph.

After enough years, I'm convinced they were a foundational mistake in POSIX. We need to move past them and stop this mistake from being repeated. More in my SambaXP talk :-).

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

Posted Feb 15, 2022 20:13 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You can transform the tree into a graph using bind mounts. So arguably it's the POSIX API that is not beautiful.

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

Posted Feb 16, 2022 18:55 UTC (Wed) by jra (subscriber, #55261) [Link]

Bind mounts are an interesting case. They're much newer than symlinks, and the security implications of allowing any user to perform them are not yet well explored. But they are a separate user-initiated operation which is not normally exposed over network filesystems, making them really a local-only attack.

They actually change the view of the filesystem hierarchy in a way that symlinks don't. Symlinks are a point attack that can modify a specific path quickly and easily to anywhere on the filesystem if allowed or exposed over a network filesystem. IMHO they are much more dangerous.

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

Posted Feb 15, 2022 19:45 UTC (Tue) by Wol (subscriber, #4433) [Link] (3 responses)

> Which OS do you use that doesn't have symlinks?

DID I use ... they pre-date linux, MacOS and Windows ...

A Multics-derivative called Pr1mos, various DOSes (I don't think I used CP/M ...) (and I don't mean MS-DOS and derivatives ...)

There used to be a world with many different OSes, not just the three behemoths we have now.

Cheers,
Wol

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

Posted Feb 16, 2022 15:06 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

Classic macos didn't have symlinks either. It did have "aliases", but those were (and are -- they still exist in modern macos, alongside symlinks and hardlinks and copy-on-write copies..) more akin to windows lnk files, as they're resolved at a higher level than basic filesystem traversal.

This allows them to be less fragile -- they store multiple ways of finding the original file, so it can still be used even in case the target has been moved or renamed. They can also do things like display a gui prompt to ask the user to insert the appropriate floppy disk which contains the target file, or automatically mount the proper remote volume.

However, the downside is that they are not functional for command-line/cross platform programs, which don't use alias-aware file access apis.

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

Posted Feb 17, 2022 12:52 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

> However, the downside is that they are not functional for command-line/cross platform programs, which don't use alias-aware file access apis.

But classic MacOS had no support for command-line apps which solved that problem.

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

Posted Feb 19, 2022 21:56 UTC (Sat) by foom (subscriber, #14868) [Link]

Classic macos did, kinda, have a shell, shell scripts, and command line apps, in MPW (https://en.m.wikipedia.org/wiki/Macintosh_Programmer's_Workshop). But that was just an app, not the fundamental underpinnings of the system.

(Of course modern macos does have both command line POSIX apps and aliases)

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

Posted Feb 16, 2022 14:22 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

> * If a file is deleted and replaced (i.e. the ubiquitous "atomic rename" pattern) this breaks hard links, but not symlinks.

Some programs still break symlinks because they operate on the pathname, not the result of following the symlink (basically, they replace the symlink instead of replacing the destination file).

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

Posted Feb 17, 2022 14:43 UTC (Thu) by Karellen (subscriber, #67644) [Link]

I think the parent commenter was referring to the case where you have a symlink somewhere pointing to /foo/bar, and /foo/bar is replaced through its canonical path, rather than through the symlink. In that case, the symlink (wherever it is) remains pointing at the new /foo/bar

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

Posted Feb 23, 2022 12:11 UTC (Wed) by anton (subscriber, #25547) [Link] (1 responses)

* Symlinks interact better with filesystem quotas. If you can create a hard link to a file owned by another user in a location they can't access, and the original path is later deleted, then you can cause that part of their quota to be permanently inaccessible to them. (Alternatively, the system can disallow hard links to other user's files—in which case the advantage of symlinks is not having this restriction.)

Given that ownership (and pretty much all other metadata) is stored with the inode, and a hard link is just another reference to the same inode, it's impossible to create a hard link with different ownership (or other metadata) than the original. On some file systems you can create a reflink (new inode, shared data); I don't know how these file systems implement the quota in this case, but IMO the way to handle this is to blame the cost of the file in full on all users (i.e., as in a regular copy).

[/tmp:128248] ls -l foo
-rw-r--r-- 1 root root 4 Feb 23 12:56 foo
[/tmp:128249] ln foo bar
ln: failed to create hard link 'bar' => 'foo': Operation not permitted
[/tmp:128251] cp --reflink foo bar
[/tmp:128252] ls -l bar
-rw-r--r-- 1 anton users 4 Feb 23 12:57 bar

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

Posted Feb 23, 2022 19:37 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> Given that ownership (and pretty much all other metadata) is stored with the inode, and a hard link is just another reference to the same inode, it's impossible to create a hard link with different ownership (or other metadata) than the original.

Yes, but you can create a hardlink to a file you don't own in a location which the owner of the hardlinked inode can't access. If they later lose their own path to the inode (by unlinking it, for example) then the inode continues to exist, because of the hardlink, and thus continues to count against their quota, but they have no way to remove it.