On 01/29/2018 03:31 PM, Viktor Dukhovni wrote: > > This issue affects a lot more than just Postfix, for example tar(1) > when run as root will chown files to the owner listed in the archive > metadata, and is almost certainly equally exposed.
I'm not 100% sure, but it looks like GNU tar will use fchown on the newly-extracted fd to avoid this problem. But you're right that a lot of other software does the same thing. > Therefore, while it may be possible to attempt to work around this > in Postfix, the only sensible solution is at the OS level. Alas, those linking restrictions are still disabled by default on a vanilla linux kernel (upstream rejected the patch to enable them), and on every non-linux OS. If you absolutely must do a recursive, *automated* ownership change, the best defense that I'm aware of is to immediately call fstatat() on the fd obtained from openat() at each stage of the recursive traversal. If the descriptor has more than one link, reject it as suspicious. There's still a tiny window between openat() and fstatat() where the attacker can delete his link (so that your fd points to something juicy, but the link count is 1), but AFAIK that's as good as it gets. If you need to do a recursive chown that isn't automated -- like for example to update $old_mail_owner to $new_mail_owner -- then e.g. GNU chown has the "--from" option to prevent $old_mail_owner from introducing hard links. The best case is when you don't really need to do the recursive chown at all. Since we have $queue_directory:d:root:-:755:uc it's safe for root to call chown non-recursively on "active/" and friends. Afterwards, the $mail_owner himself should be creating things in "active/" and the only way for them to have some other owner would be if root changed it. Do we want postfix to "fix" things in that case? Maybe as a last resort... but as part of the standard upgrade procedure?
