linux-kernel - Re: [PATCH] mount -o noexdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160508194641.GG2694@ZenIV.linux.org.uk>
Date:	Sun, 8 May 2016 20:46:41 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mount -o noexdev

On Sun, May 08, 2016 at 09:35:42PM +0300, Alexey Dobriyan wrote:
> Searching for "rename bint mount exdev" shows that failure with EXDEV
> seems somewhat unintuitive behaviour. Allow users to bypass
> this restriction with "-o noexdev" flag if the source of operation is on
> such mount.
> 
> Keep old semantics default so "mount --bind /tmp /tmp" works.
> 
> "mount --bind" will inherit "noexdev" flag from parent mount but it can
> be cleared with mount(MS_REMOUNT) so it is possible to create exclave
> with regular mount point crossing rules inside mount with relaxed mount
> point rules.

NAK.  At least until you bother to explore the consequences of such
rename for vfsmounts involved.  Hint: look at the semantics of ..
and mountpoint crossing.

It's a bloody bad idea; we have to cope with attackers who'd managed to
do that kind of rename using a mount of a bigger subtree, but that's
"cope" - it's not a normal situation and the price is non-trivial.

... and before you go into "if you don't want it, don't mount that way, what's
the problem?", consider our, ah, noble adversaries who'd been very clear
regarding their treatment of any optional features.  I do _not_ want to
end up with the situation when systemd-infested distributions run the setups
that use this thing and any reports along the lines "it's trivial to degrade
the performance on that setup" get bounced our way.  With "no, we are not
going to stop depending on that feature; if the kernel folks had a problem with
it, they shouldn't have merged it in the first place" tacked on top of those
reports.