Kaz Kylheku (Coreutils) wrote:
Instead of checking for what *could* go wrong, why not defend more specifically against signs that the attack might be actually happening.
That's what the patch is trying to do, though it looks like it should be improved.
Somehow detect, "Uh oh! Parent is writable by another non-root user, and the last component opened through a symlink!"
We can't do that check atomically, unfortunately. However, there are approximations that should be good enough. I will think through this more carefully. In the end, though, there will be no way to avoid all false positives and all false negatives: we will need to err one way or the other, probably both. The goal will be an engineering one: have so few false negatives that attackers give up and do other things, and have so few false positives that their cost is outweighed by the benefit of the true positives.
it occurs to me that the attack can be perpetrated if any of the ancestral directories are writable to another non-root user.
Yes, and that's a problem that I am not trying to address. The Linux /proc/sys/fs/protected_symlinks approach doesn't try to address it either. It'd be too much hassle for Coreutils to address it, for too little benefit. The only problem I am trying to address is foiling attempts to create children of vulnerable directories, because these are where the bulk of the real-world vulnerabilities are. The Linux kernel is the same way.
I am thinking of reverting my patch (at Pádraig's gentle suggestion) and coming up with a better one in the light of recent comments. Perhaps it'll be two patches, since we have two kinds of attacks here and that's causing some of the confusion.
