DotNet IPC on Linux uses TMPDIR vs /tmp

[beaubelgrave]

The DotNet IPC Diagnostic Port clearly states TMPDIR environ should be used vs /tmp. We currently use /tmp and need to check TMPDIR instead to accurately reflect the specification.

[bluca]

tmp/tmpdir should really be avoided for sockets/IPC, unless absolutely necessary. They are world-writable by default, and that means bad actors can do bad things.

The best approach is a pattern such as:

if [ -d "$RUNTIME_DIRECTORY" ] && [ -w "$RUNTIME_DIRECTORY" ]; then
       DIR="$RUNTIME_DIRECTORY"
elif [ -d "$XDG_RUNTIME_DIR" ] && [ -w "$XDG_RUNTIME_DIR" ]; then
       DIR="$XDG_RUNTIME_DIR"
elif [ -d "$TMPDIR" ] && [ -w "$TMPDIR" ]; then
       DIR="$TMPDIR"
else
       DIR="/tmp/"
fi

Then if the program runs as a service, it can use RuntimeDirectory= to have its lifecycle maintained automatically. If it runs as a user, it can use the standard xdg runtime dir so that other unprivileged users can't access it.

If you really can't avoid tmpdir because you run manually and unprivileged and required multiple unprivileged uids to communicate directly, then make sure to use mkdtemp or so to avoid issues https://systemd.io/TEMPORARY_DIRECTORIES/
and make sure to use a bsd lock file to avoid tmpfiles.d autocleanup while in use

[beaubelgrave]

@noahfalk is this something .NET can change based on Luca's comments?

[noahfalk]

The location of that socket is part of a contract between diagnostic tools and the runtime that has been in place since about 2019. Any change to it implies all the old versions of tools stop working. Its not written in stone, but its also not something we'd want to change casually.

For the security part we do assume that a local attacker could spoof the socket. We wanted to protect .NET runtime apps against other malicious users, but we don't protect diagnostic tools against malicious apps. If anyone believes its an insufficient security boundary or wants to discuss the security part further we might want to do that via offline chat or a security issue. For functional concerns (ensuring the socket doesn't get aged out) we could do that in a GH issue over in the runtime repo. Hope that helps!

[bluca]

It's a really well known anti-pattern, so it would be really advisable to start with a migration plan. You can do it in a backward compatible way, eg: start checking for the new path and if nothing's there, then check the old path, and start advising clients to migrate. It can be done slowly, but eventually it will be done. Seems better than doing nothing?

[noahfalk]

I'm looking into it more, we are just discouraged from discussing security-related things in public :)

[bluca]

I understand, but I think this can be considered as a hardening exercise rather than a security issue, as there's no active exploit or anything like that