[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151104144619.GB19527@mail.hallyn.com>
Date: Wed, 4 Nov 2015 08:46:19 -0600
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Kees Cook <keescook@...omium.org>
Cc: Dirk Steinmetz <public@...tdrjgfuzkfg.com>,
Serge Hallyn <serge.hallyn@...ntu.com>,
Seth Forshee <seth.forshee@...onical.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Serge Hallyn <serge.hallyn@...onical.com>
Subject: Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids
On Tue, Nov 03, 2015 at 10:20:38AM -0800, Kees Cook wrote:
> On Mon, Nov 2, 2015 at 4:39 PM, Dirk Steinmetz
> <public@...tdrjgfuzkfg.com> wrote:
> > In order to hardlink to a sgid-executable, it is sufficient to be the
> > file's owner. When hardlinking within an unprivileged user namespace, the
> > users of that namespace could thus use hardlinks to pin setgid binaries
> > owned by themselves (or any mapped uid, with CAP_FOWNER) and a gid outside
> > of the namespace. This is a possible security risk.
>
> How would such a file appear within the namespace? Wouldn't the gid
> have to map to something inside the namespace?
Inside the namespace it would appear as gid -1. Outside the namespace
it would appear as the real gid. So the problem would be if I am allowed
to map the file owning uid but not gid; I make a new link to the file;
I wait for a vulnerability to be found; host admin updates the original
file; now on the host I run the file - having learned how to exploit the
vulnerability through no ingenuity of my own - and own all files owned
by that gid.
-serge
--
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