From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934717AbdC3TMz (ORCPT ); Thu, 30 Mar 2017 15:12:55 -0400 Received: from mail-vk0-f48.google.com ([209.85.213.48]:36350 "EHLO mail-vk0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934299AbdC3TMx (ORCPT ); Thu, 30 Mar 2017 15:12:53 -0400 MIME-Version: 1.0 In-Reply-To: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> References: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> From: Andy Lutomirski Date: Thu, 30 Mar 2017 12:12:31 -0700 Message-ID: Subject: Re: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace To: Djalal Harouni Cc: Linux Kernel Mailing List , Andy Lutomirski , Alexey Gladkov , Al Viro , "Eric W. Biederman" , Andrew Morton , Linux API , "Kirill A. Shutemov" , Oleg Nesterov , Pavel Emelyanov , James Bottomley , Kees Cook , Dongsu Park , Ingo Molnar , Michal Hocko , Alexey Dobriyan , "kernel-hardening@lists.openwall.com" , LSM List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v2UJE0rM017040 On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use case face. > > Historically procfs was tied to pid namespaces, and mount options were > propagated to all other procfs instances in the same pid namespace. This > solved several use cases in that time. However today we face new > problems, there are mutliple container implementations there, some of > them want to hide pid entries, others want to hide non-pid entries, > others want to have sysctlfs, others want to share pid namespace with > private procfs mounts. All these with current implementation won't work > since all options will be propagated to all procfs mounts. > > This series allow to have new instances of procfs per pid namespace where > each instance can have its own mount option inside the same pid namespace. > This was also suggested by Andy Lutomirski. > > > Now: > $ sudo mount -t proc -o unshare,hidepid=2 none /test > > The option 'unshare' will allow to mount a new instance of procfs inside > the same pid namespace. > > Before: > $ stat /proc/slabinfo > > File: ‘/proc/slabinfo’ > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: ‘/test3/slabinfo’ > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > > After: > $ stat /proc/slabinfo > > File: ‘/proc/slabinfo’ > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: ‘/test3/slabinfo’ > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 31h/49d Inode: 4026532046 Links: 1 > > > Any better name for the option 'unshare' ? suggestions ? > > I was going to use 'version=2' but then this may sound more like a > proc2 fs which currently impossible to implement since it will share > locks with the old proc. > > > Al, Eric any comments please ? I like the concept, except that I think it would be nice to avoid needing 'unshare', perhaps by making unsharing the default and making hidepid work backwards compatibly if needed. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace Date: Thu, 30 Mar 2017 12:12:31 -0700 Message-ID: References: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1490887379-25880-1-git-send-email-tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Djalal Harouni Cc: Linux Kernel Mailing List , Andy Lutomirski , Alexey Gladkov , Al Viro , "Eric W. Biederman" , Andrew Morton , Linux API , "Kirill A. Shutemov" , Oleg Nesterov , Pavel Emelyanov , James Bottomley , Kees Cook , Dongsu Park , Ingo Molnar , Michal Hocko , Alexey Dobriyan , "kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org" , LSM List List-Id: linux-api@vger.kernel.org On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use case face. > > Historically procfs was tied to pid namespaces, and mount options were > propagated to all other procfs instances in the same pid namespace. This > solved several use cases in that time. However today we face new > problems, there are mutliple container implementations there, some of > them want to hide pid entries, others want to hide non-pid entries, > others want to have sysctlfs, others want to share pid namespace with > private procfs mounts. All these with current implementation won't work > since all options will be propagated to all procfs mounts. > > This series allow to have new instances of procfs per pid namespace where > each instance can have its own mount option inside the same pid namespace= . > This was also suggested by Andy Lutomirski. > > > Now: > $ sudo mount -t proc -o unshare,hidepid=3D2 none /test > > The option 'unshare' will allow to mount a new instance of procfs inside > the same pid namespace. > > Before: > $ stat /proc/slabinfo > > File: =E2=80=98/proc/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: =E2=80=98/test3/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > > After: > $ stat /proc/slabinfo > > File: =E2=80=98/proc/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: =E2=80=98/test3/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 31h/49d Inode: 4026532046 Links: 1 > > > Any better name for the option 'unshare' ? suggestions ? > > I was going to use 'version=3D2' but then this may sound more like a > proc2 fs which currently impossible to implement since it will share > locks with the old proc. > > > Al, Eric any comments please ? I like the concept, except that I think it would be nice to avoid needing 'unshare', perhaps by making unsharing the default and making hidepid work backwards compatibly if needed. From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto@amacapital.net (Andy Lutomirski) Date: Thu, 30 Mar 2017 12:12:31 -0700 Subject: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace In-Reply-To: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> References: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use case face. > > Historically procfs was tied to pid namespaces, and mount options were > propagated to all other procfs instances in the same pid namespace. This > solved several use cases in that time. However today we face new > problems, there are mutliple container implementations there, some of > them want to hide pid entries, others want to hide non-pid entries, > others want to have sysctlfs, others want to share pid namespace with > private procfs mounts. All these with current implementation won't work > since all options will be propagated to all procfs mounts. > > This series allow to have new instances of procfs per pid namespace where > each instance can have its own mount option inside the same pid namespace. > This was also suggested by Andy Lutomirski. > > > Now: > $ sudo mount -t proc -o unshare,hidepid=2 none /test > > The option 'unshare' will allow to mount a new instance of procfs inside > the same pid namespace. > > Before: > $ stat /proc/slabinfo > > File: ?/proc/slabinfo? > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: ?/test3/slabinfo? > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > > After: > $ stat /proc/slabinfo > > File: ?/proc/slabinfo? > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: ?/test3/slabinfo? > Size: 0 Blocks: 0 IO Block: 1024 regular empty file > Device: 31h/49d Inode: 4026532046 Links: 1 > > > Any better name for the option 'unshare' ? suggestions ? > > I was going to use 'version=2' but then this may sound more like a > proc2 fs which currently impossible to implement since it will share > locks with the old proc. > > > Al, Eric any comments please ? I like the concept, except that I think it would be nice to avoid needing 'unshare', perhaps by making unsharing the default and making hidepid work backwards compatibly if needed. -- 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 MIME-Version: 1.0 In-Reply-To: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> References: <1490887379-25880-1-git-send-email-tixxdz@gmail.com> From: Andy Lutomirski Date: Thu, 30 Mar 2017 12:12:31 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: [PATCH RFC 0/4] proc: support multiple separate proc instances per pidnamespace To: Djalal Harouni Cc: Linux Kernel Mailing List , Andy Lutomirski , Alexey Gladkov , Al Viro , "Eric W. Biederman" , Andrew Morton , Linux API , "Kirill A. Shutemov" , Oleg Nesterov , Pavel Emelyanov , James Bottomley , Kees Cook , Dongsu Park , Ingo Molnar , Michal Hocko , Alexey Dobriyan , "kernel-hardening@lists.openwall.com" , LSM List List-ID: On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote: > Hi, > > This RFC can be applied on top of Linus' tree 89970a04d7 > > This RFC implements support for multiple separate proc instances inside > the same pid namespace. This allows to solve lot of problems that > today's use case face. > > Historically procfs was tied to pid namespaces, and mount options were > propagated to all other procfs instances in the same pid namespace. This > solved several use cases in that time. However today we face new > problems, there are mutliple container implementations there, some of > them want to hide pid entries, others want to hide non-pid entries, > others want to have sysctlfs, others want to share pid namespace with > private procfs mounts. All these with current implementation won't work > since all options will be propagated to all procfs mounts. > > This series allow to have new instances of procfs per pid namespace where > each instance can have its own mount option inside the same pid namespace= . > This was also suggested by Andy Lutomirski. > > > Now: > $ sudo mount -t proc -o unshare,hidepid=3D2 none /test > > The option 'unshare' will allow to mount a new instance of procfs inside > the same pid namespace. > > Before: > $ stat /proc/slabinfo > > File: =E2=80=98/proc/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: =E2=80=98/test3/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > > After: > $ stat /proc/slabinfo > > File: =E2=80=98/proc/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 4h/4d Inode: 4026532046 Links: 1 > > $ stat /test3/slabinfo > > File: =E2=80=98/test3/slabinfo=E2=80=99 > Size: 0 Blocks: 0 IO Block: 1024 regular empty= file > Device: 31h/49d Inode: 4026532046 Links: 1 > > > Any better name for the option 'unshare' ? suggestions ? > > I was going to use 'version=3D2' but then this may sound more like a > proc2 fs which currently impossible to implement since it will share > locks with the old proc. > > > Al, Eric any comments please ? I like the concept, except that I think it would be nice to avoid needing 'unshare', perhaps by making unsharing the default and making hidepid work backwards compatibly if needed.