linux-kernel - Re: [PATCH v4 3/5] fuse: Restrict allow_other to uids already controlled by the user

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Oct 2014 17:11:00 +0200
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	fuse-devel@...ts.sourceforge.net,
	"Serge H. Hallyn" <serge.hallyn@...ntu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v4 3/5] fuse: Restrict allow_other to uids already
 controlled by the user

On Wed, Oct 15, 2014 at 07:58:59AM -0700, Andy Lutomirski wrote:
> On 10/14/2014 07:25 AM, Seth Forshee wrote:
> > Unprivileged users are normally restricted from mounting with the
> > allow_other option by system policy, but this could be bypassed
> > for a mount done with user namespace root permissions. In such
> > cases allow_other should not allow users outside the user
> > namespace to access the mount as doing so would give the
> > unprivileged user the ability to manipulate processes it would
> > otherwise be unable to manipulate.
> 
> What threat is this intended to protect against?  I think that, if this
> is needed, tasks outside the userns or its descendents should be
> blocked, even if the user ids match.  That is, I think you should check
> the namespace, not the uid and gid.

allow_other is an existing option in fuse to protect against DoS
attacks against more privileged users by making file operations block
indefinitely. So this change makes it work the same way inside a user
namespace but only to users mapped into the namespace. Checking the
namespace does seem to make more sense, so I'll make that change.

Thanks,
Seth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/