From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Berger Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Wed, 12 Jul 2017 20:44:28 -0400 Message-ID: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <877ezdgsey.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" , "Serge E. Hallyn" Cc: lkp-JC7UmRfGjtg@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org List-Id: containers.vger.kernel.org On 07/12/2017 07:13 PM, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > >> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org): >>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes: >>>> Signed-off-by: Stefan Berger >>>> Signed-off-by: Serge Hallyn >>>> Reviewed-by: Serge Hallyn >>> It doesn't look like this is coming through Serge so I don't see how >>> the Signed-off-by tag is legtimate. >> This is mostly explained by the fact that there have been a *lot* of >> changes, many of them discussed in private emails. >> >>> >From the replies to this it doesn't look like Serge has reviewed this >>> version either. >>> >>> I am disappointed that all of my concerns about technical feasibility >>> remain unaddressed. >> Can you re-state those, or give a link to them? > Well I only posted about one substantive comment on the last round > so it should be easy to find that said. > > The big question is how does this intereact with filesystems > xattr implementations? > > There is the potential that we create many more security xattrs this > way. How does that scale? With more names etc. It doesn't scale. Shared filesystems are a problem if many containers use them. 'man listxattr' also mentions this here as a BUG: " As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of the extended attribute name list returned by listxattr(7). If the total size of attribute names attached to a file exceeds this limit, it is no longer possible to retrieve the list of attribute names." A simple test on ext4: #> touch foo #> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello foo; done user.foo126 was the last one created... Depending on the size of the data the xattrs are writing, the limit is reached sooner. Writing 'hellohello' only goes up to 'user.foo112'. Maybe one could try to encode the data more efficiently or as Serge did write the uid on the xattr value side, but either way, it won't scale due to that VFS limit. Stefan > What happens if we have one xattr per uid for 1000+ uids? > > How does this interact with filesystems optimization of xattr names? > For some filesystems they optmize the xattr names, and don't store the > entire thing. > >> I'd really like to get to a point where unprivileged containers can start >> using filecaps - at this point if that means having an extra temporary >> file format based on my earlier patchset while we hash this out, that >> actually seems worthwhile. But it would of course be ideal if we could >> do the name based caps right in the first place. > This whole new version has set my review back to square one > unfortunately. > > Eric > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751231AbdGMAoj (ORCPT ); Wed, 12 Jul 2017 20:44:39 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51955 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751073AbdGMAog (ORCPT ); Wed, 12 Jul 2017 20:44:36 -0400 Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces To: "Eric W. Biederman" , "Serge E. Hallyn" References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> Cc: containers@lists.linux-foundation.org, lkp@01.org, linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com, tycho@docker.com, James.Bottomley@HansenPartnership.com, vgoyal@redhat.com, christian.brauner@mailbox.org, amir73il@gmail.com, linux-security-module@vger.kernel.org, casey@schaufler-ca.com From: Stefan Berger Date: Wed, 12 Jul 2017 20:44:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <877ezdgsey.fsf@xmission.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17071300-0048-0000-0000-000001C2C4A9 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007358; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00886734; UDB=6.00442659; IPR=6.00666883; BA=6.00005469; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016203; XFM=3.00000015; UTC=2017-07-13 00:44:33 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071300-0049-0000-0000-000041DE0793 Message-Id: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-12_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707130010 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/12/2017 07:13 PM, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > >> Quoting Eric W. Biederman (ebiederm@xmission.com): >>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes: >>>> Signed-off-by: Stefan Berger >>>> Signed-off-by: Serge Hallyn >>>> Reviewed-by: Serge Hallyn >>> It doesn't look like this is coming through Serge so I don't see how >>> the Signed-off-by tag is legtimate. >> This is mostly explained by the fact that there have been a *lot* of >> changes, many of them discussed in private emails. >> >>> >From the replies to this it doesn't look like Serge has reviewed this >>> version either. >>> >>> I am disappointed that all of my concerns about technical feasibility >>> remain unaddressed. >> Can you re-state those, or give a link to them? > Well I only posted about one substantive comment on the last round > so it should be easy to find that said. > > The big question is how does this intereact with filesystems > xattr implementations? > > There is the potential that we create many more security xattrs this > way. How does that scale? With more names etc. It doesn't scale. Shared filesystems are a problem if many containers use them. 'man listxattr' also mentions this here as a BUG: " As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of the extended attribute name list returned by listxattr(7). If the total size of attribute names attached to a file exceeds this limit, it is no longer possible to retrieve the list of attribute names." A simple test on ext4: #> touch foo #> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello foo; done user.foo126 was the last one created... Depending on the size of the data the xattrs are writing, the limit is reached sooner. Writing 'hellohello' only goes up to 'user.foo112'. Maybe one could try to encode the data more efficiently or as Serge did write the uid on the xattr value side, but either way, it won't scale due to that VFS limit. Stefan > What happens if we have one xattr per uid for 1000+ uids? > > How does this interact with filesystems optimization of xattr names? > For some filesystems they optmize the xattr names, and don't store the > entire thing. > >> I'd really like to get to a point where unprivileged containers can start >> using filecaps - at this point if that means having an extra temporary >> file format based on my earlier patchset while we hash this out, that >> actually seems worthwhile. But it would of course be ideal if we could >> do the name based caps right in the first place. > This whole new version has set my review back to square one > unfortunately. > > Eric > From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefanb@linux.vnet.ibm.com (Stefan Berger) Date: Wed, 12 Jul 2017 20:44:28 -0400 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: <877ezdgsey.fsf@xmission.com> References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> Message-ID: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 07/12/2017 07:13 PM, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > >> Quoting Eric W. Biederman (ebiederm at xmission.com): >>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes: >>>> Signed-off-by: Stefan Berger >>>> Signed-off-by: Serge Hallyn >>>> Reviewed-by: Serge Hallyn >>> It doesn't look like this is coming through Serge so I don't see how >>> the Signed-off-by tag is legtimate. >> This is mostly explained by the fact that there have been a *lot* of >> changes, many of them discussed in private emails. >> >>> >From the replies to this it doesn't look like Serge has reviewed this >>> version either. >>> >>> I am disappointed that all of my concerns about technical feasibility >>> remain unaddressed. >> Can you re-state those, or give a link to them? > Well I only posted about one substantive comment on the last round > so it should be easy to find that said. > > The big question is how does this intereact with filesystems > xattr implementations? > > There is the potential that we create many more security xattrs this > way. How does that scale? With more names etc. It doesn't scale. Shared filesystems are a problem if many containers use them. 'man listxattr' also mentions this here as a BUG: " As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of the extended attribute name list returned by listxattr(7). If the total size of attribute names attached to a file exceeds this limit, it is no longer possible to retrieve the list of attribute names." A simple test on ext4: #> touch foo #> for ((i = 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello foo; done user.foo126 was the last one created... Depending on the size of the data the xattrs are writing, the limit is reached sooner. Writing 'hellohello' only goes up to 'user.foo112'. Maybe one could try to encode the data more efficiently or as Serge did write the uid on the xattr value side, but either way, it won't scale due to that VFS limit. Stefan > What happens if we have one xattr per uid for 1000+ uids? > > How does this interact with filesystems optimization of xattr names? > For some filesystems they optmize the xattr names, and don't store the > entire thing. > >> I'd really like to get to a point where unprivileged containers can start >> using filecaps - at this point if that means having an extra temporary >> file format based on my earlier patchset while we hash this out, that >> actually seems worthwhile. But it would of course be ideal if we could >> do the name based caps right in the first place. > This whole new version has set my review back to square one > unfortunately. > > Eric > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2624714779747725858==" MIME-Version: 1.0 From: Stefan Berger To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Wed, 12 Jul 2017 20:44:28 -0400 Message-ID: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> In-Reply-To: <877ezdgsey.fsf@xmission.com> List-Id: --===============2624714779747725858== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/12/2017 07:13 PM, Eric W. Biederman wrote: > "Serge E. Hallyn" writes: > >> Quoting Eric W. Biederman (ebiederm(a)xmission.com): >>> Stefan Berger <"Stefan Bergerstefanb"@linux.vnet.ibm.com> writes: >>>> Signed-off-by: Stefan Berger >>>> Signed-off-by: Serge Hallyn >>>> Reviewed-by: Serge Hallyn >>> It doesn't look like this is coming through Serge so I don't see how >>> the Signed-off-by tag is legtimate. >> This is mostly explained by the fact that there have been a *lot* of >> changes, many of them discussed in private emails. >> >>> >From the replies to this it doesn't look like Serge has reviewed this >>> version either. >>> >>> I am disappointed that all of my concerns about technical feasibility >>> remain unaddressed. >> Can you re-state those, or give a link to them? > Well I only posted about one substantive comment on the last round > so it should be easy to find that said. > > The big question is how does this intereact with filesystems > xattr implementations? > > There is the potential that we create many more security xattrs this > way. How does that scale? With more names etc. It doesn't scale. Shared filesystems are a problem if many containers = use them. 'man listxattr' also mentions this here as a BUG: " As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of the extended attribute name list returned by listxattr(7). If the total size of attribute names attached to a file exceeds this limit, it is no longer possible to retrieve the list of attribute names." A simple test on ext4: #> touch foo #> for ((i =3D 0; i < 200; i++)); do setfattr -n user.foo${i} -v hello = foo; done user.foo126 was the last one created... Depending on the size of the data the xattrs are writing, the limit is = reached sooner. Writing 'hellohello' only goes up to 'user.foo112'. = Maybe one could try to encode the data more efficiently or as Serge did = write the uid on the xattr value side, but either way, it won't scale = due to that VFS limit. Stefan > What happens if we have one xattr per uid for 1000+ uids? > > How does this interact with filesystems optimization of xattr names? > For some filesystems they optmize the xattr names, and don't store the > entire thing. > >> I'd really like to get to a point where unprivileged containers can start >> using filecaps - at this point if that means having an extra temporary >> file format based on my earlier patchset while we hash this out, that >> actually seems worthwhile. But it would of course be ideal if we could >> do the name based caps right in the first place. > This whole new version has set my review back to square one > unfortunately. > > Eric > --===============2624714779747725858==--