Hello,
You are correct, it would be a configuration error. But the issue is
that when a rootdir is set, export entries are assumed to be relative to
the rootdir path, but this isn't the case. So my rootdir can have a
restrictive set of permissions, but the export entry path relative to
the system* rootdir may have an entirely different set of permissions.
Or even with restrictive permissions it could be accidentally or
maliciously symlinked.
Christopher Bii
NeilBrown wrote:
On Sat, 07 Dec 2024, Christopher Bii wrote:
Hello,
It is hinted in the configuration files that an attacker could gain access
to arbitrary folders by guessing symlink paths that match exported dirs,
but this is not the case. They can get access to the root export with
certainty by simply symlinking to "../../../../../../../", which will
always return "/".
This is due to realpath() being called in the main thread which isn't
chrooted, concatenating the result with the export root to create the
export entry's final absolute path which the kernel then exports.
PS: I already sent this patch to the mailing list about the same subject
but it was poorly formatted. Changes were merged into a single commit. I
have broken it up into smaller commits and made the patch into a single
thread. Pardon the mistake, first contribution.
I'm still not convinced there is a vulnerability here, but I might have
missed part of the conversation...
Could you please spell out in detail the threat scenario that we are
trying to defend against?
From my perspective: if you export a path that a non-privileged user can
modify, then that is a configuration error. We should not try to make
it "safe". We could possibly try to detect that situation and fail the
export when it happens.
Why is that perspective not correct? If this has already been
discussed, please point me to the relevant email.
Thanks,
NeilBrown
