linux-kernel - Re: [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps.

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: <87wqwkz4vm.fsf@xmission.com>
Date:	Fri, 14 Dec 2012 13:43:41 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	containers@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps.

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Fri, Dec 14, 2012 at 10:12 AM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>>
>> That said Serge I think I have lost track of the point of your question.
>
> .. and I'm a bit unsure what I should do about this all. Including
> pulling the pull request that actually can make this all matter.
>
> Hmm? Any consensus?

It looks like we have consensus (baring the color of the shed)
of what the code should look like for v3.8.

>From the most embarrassingly timed, but most useful review by Andy I have
4 fixes queued up in my development tree.

Fixing cap_capable to test for the parent namespace.
Fixing setns to require nsown_capable(CAP_SYS_ADMIN)
--
Fixing commit_creds to not clear task dumpable unnecessarily.
Fixing a typo in the description.

What I would like to do is to do is what I would if this was not the
middle of the merge window with changes like this.

Toss those patches out for last round of review.

Possibly toss the last two patches if there are any problems because
they are not necessary.

Put the patches in my for-next branch and have them sit in linux-next
for a day or three. 

Send you an updated pull request.

I am recovering from a cold so I am running slower than I would like
this week and would really rather not rush getting these patches out.

What I don't want to be is so cautious and careful that you decide to
pass on my pull request.  The code is harmless with user namespaces
disabled.  The code has been baking for a long time, some of it for much
too long and it is as solid as I think it will get out before being
merged.  Nor is the code complex Andy managed to dig and figure it all
out in about a day.

Linus does that work for you?

Eric
--
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/