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]
Message-ID: <20141015151100.GA988@ubuntu-mba51>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ