Show HN: Code in Response to “The Trouble with Symlinks.” | Hacker News Reader

Show HN: Code in Response to “The Trouble with Symlinks.”

kylheku.com

5 pointskazinator4 comments

See: https://news.ycombinator.com/item?id=32190032

This was written in about the past hour or so; it has no documentation or test cases yet. Think twice before relying on it in production.

The idea is that we can perform a detailed validation of the trustworthiness of an absolute or relative path, as a simple function that can be reused anywhere: I call this function safepath_check.

A trustworthy path is one whose meaning cannot be changed by a third party: another user who isn't root.

The path is therefore immune, for instance, to TOCtoTOU security problems, like the insertion of a symbolic link or other tampering.

A trustworthy path is allowed to contain symbolic links. Symbolic links can be validated to be safe. To that end, safepath_check performs its own symlink resolution, to ensure that every link resolution step substitutes path material that is trustworthy.

Open articleView on HN

This code doesn't work and has security holes via race conditions.

You cannot walk a path using lstat and readlink. Once you have walked past a component you have checked, an attacker can change it to point elsewhere.

You must use openat() and readlinkat() to have any hope of symlink security.

As my talk already pointed out. The POSIX file API is impossible to use safely for programmers.

I'm afraid you just illustrated my point perfectly.

It works by induction. If there is a path alpha that we somehow trust, we can also trust alpha/omega if omega is a symlink. We cannot trust what it points to, but we can trust that omega itself is not editable by an adversary. That allows us to read the symlink and continue analyzing.

Anyway, I would be delighted to see a program which can fool the safepath_check function, so that it reports to user Alice that a path is safe in spite of Mallory controlling one or more components. I will try to fix the function to close the hole, and of course give full credit.

What if the real and effective user IDs do not match? Would it be necessary to make a consideration for such a case?

Thanks for raising the question.

The code should probably be using the effective and not the real ID.

We are not answering the question "is this path safe for the user who started this process", because that is not relevant. We need to know "is this path safe relative to the privilege and scope of the identity we are actually wielding to access the system".

The access function in POSIX uses the real ID; but that is because its purpose is to determine, in a setuid program, what the original user can/cannot access. (In situations when it would be cumbersome to temporarily change the effective ID to the real one to try the actual access.)

The real ID should not be used for checks which are not access checks, but rather "how can the environment harm me". The effective user does not trust the real user. Concretely, a setuid root binary run by user "bob" doesn't want to trust a symlink or directory that is modifiable by "bob". (If it wants to do such a trust check on behalf of "bob", it can call seteuid(getuid()) to become "bob" first).

Reply on news.ycombinator.com