On Fri, Nov 10, 2017 at 1:46 PM, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> single sandbox. I am not at all certain that the capabilities is the
>> proper place to limit code reachability.
>
> Right, I keep having this gut feeling that there is another way we
>
Quoting Eric W. Biederman (ebied...@xmission.com):
> single sandbox. I am not at all certain that the capabilities is the
> proper place to limit code reachability.
Right, I keep having this gut feeling that there is another way we
should be doing that. Maybe based on ksplice or perf, or maybe m
On Fri, Nov 10, 2017 at 6:58 AM, Eric W. Biederman
wrote:
> "Mahesh Bandewar (महेश बंडेवार)" writes:
>
>> [resend response as earlier one failed because of formatting issues]
>>
>> On Thu, Nov 9, 2017 at 12:21 PM, Serge E. Hallyn wrote:
>>>
>>> On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Ba
On Fri, Nov 10, 2017 at 2:25 AM, Serge E. Hallyn wrote:
> Quoting Mahesh Bandewar (mah...@bandewar.net):
>> From: Mahesh Bandewar
>>
>> With this new notion of "controlled" user-namespaces, the controlled
>> user-namespaces are marked at the time of their creation while the
>> capabilities of pro
"Mahesh Bandewar (महेश बंडेवार)" writes:
> [resend response as earlier one failed because of formatting issues]
>
> On Thu, Nov 9, 2017 at 12:21 PM, Serge E. Hallyn wrote:
>>
>> On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार)
>> wrote:
>> > On Thu, Nov 9, 2017 at 4:02 A
On 11/09/2017 01:05 PM, Serge E. Hallyn wrote:
Would the existing capability bounding set not suffice for that?
The 'permanent' bounding set turns out to not be a good fit for
the problem being discussed in this thread, but please feel free
to start a new thread if you want to discuss your use c
Quoting chris hyser (chris.hy...@oracle.com):
> On 11/06/2017 10:23 PM, Serge E. Hallyn wrote:
> >I think I definately prefer what I mentioned in the email to Boris.
> >Basically a "permanent capability bounding set". The normal bounding
> >set gets reset to a full set on every new user_ns creatio
On 11/06/2017 10:23 PM, Serge E. Hallyn wrote:
I think I definately prefer what I mentioned in the email to Boris.
Basically a "permanent capability bounding set". The normal bounding
set gets reset to a full set on every new user_ns creation. In this
proposal, it would instead be set to the ca
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> With this new notion of "controlled" user-namespaces, the controlled
> user-namespaces are marked at the time of their creation while the
> capabilities of processes that belong to them are controlled using the
> global ma
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> Of course. Let's take an example of the CVE that I have mentioned in
> my cover-letter -
> CVE-2017-7308(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308).
> It's well documented and even has a
> exploit(https://github.com/x
[resend response as earlier one failed because of formatting issues]
On Thu, Nov 9, 2017 at 12:21 PM, Serge E. Hallyn wrote:
>
> On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार)
> wrote:
> > On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner
> > wrote:
> > > On Wed, Nov 0
On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner
> wrote:
> > On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> >> Sorry folks I was traveling and seems like lot happened on this
On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner
wrote:
> On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार)
> wrote:
>> Sorry folks I was traveling and seems like lot happened on this thread. :p
>>
>> I will try to response few of these comments selectively -
>>
>> > The t
On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार) wrote:
> Sorry folks I was traveling and seems like lot happened on this thread. :p
>
> I will try to response few of these comments selectively -
>
> > The thing that makes me hesitate with this set is that it is a
> > perm
Sorry folks I was traveling and seems like lot happened on this thread. :p
I will try to response few of these comments selectively -
> The thing that makes me hesitate with this set is that it is a
> permanent new feature to address what (I hope) is a temporary
> problem.
I agree this is permane
On Mon, Nov 06, 2017 at 07:01:58PM -0500, Boris Lukashev wrote:
> On Mon, Nov 6, 2017 at 6:39 PM, Serge E. Hallyn wrote:
> > Quoting Boris Lukashev (blukas...@sempervictus.com):
> >> On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
> >> > Quoting Daniel Micay (danielmi...@gmail.com):
> >> >
On Mon, Nov 06, 2017 at 09:16:03PM -0500, Daniel Micay wrote:
> On Mon, 2017-11-06 at 16:14 -0600, Serge E. Hallyn wrote:
> > Quoting Daniel Micay (danielmi...@gmail.com):
> > > Substantial added attack surface will never go away as a problem.
> > > There
> > > aren't a finite number of vulnerabili
On Mon, 2017-11-06 at 16:14 -0600, Serge E. Hallyn wrote:
> Quoting Daniel Micay (danielmi...@gmail.com):
> > Substantial added attack surface will never go away as a problem.
> > There
> > aren't a finite number of vulnerabilities to be found.
>
> There's varying levels of usefulness and quality.
On Mon, Nov 6, 2017 at 6:39 PM, Serge E. Hallyn wrote:
> Quoting Boris Lukashev (blukas...@sempervictus.com):
>> On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
>> > Quoting Daniel Micay (danielmi...@gmail.com):
>> >> Substantial added attack surface will never go away as a problem. There
Quoting Boris Lukashev (blukas...@sempervictus.com):
> On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
> > Quoting Daniel Micay (danielmi...@gmail.com):
> >> Substantial added attack surface will never go away as a problem. There
> >> aren't a finite number of vulnerabilities to be found.
>
On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
> Quoting Daniel Micay (danielmi...@gmail.com):
>> Substantial added attack surface will never go away as a problem. There
>> aren't a finite number of vulnerabilities to be found.
>
> There's varying levels of usefulness and quality. There i
On Mon, Nov 06, 2017 at 04:14:18PM -0600, Serge Hallyn wrote:
> Quoting Daniel Micay (danielmi...@gmail.com):
> > Substantial added attack surface will never go away as a problem. There
> > aren't a finite number of vulnerabilities to be found.
>
> There's varying levels of usefulness and quality.
Quoting Daniel Micay (danielmi...@gmail.com):
> Substantial added attack surface will never go away as a problem. There
> aren't a finite number of vulnerabilities to be found.
There's varying levels of usefulness and quality. There is code which I
want to be able to use in a container, and code
Substantial added attack surface will never go away as a problem. There
aren't a finite number of vulnerabilities to be found.
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Sat, Nov 4, 2017 at 4:53 PM, Serge E. Hallyn wrote:
> >
> > Quoting Mahesh Bandewar (mah...@bandewar.net):
> > > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> > > that belongs to uncontrolled user-ns can cre
On Sat, Nov 4, 2017 at 4:53 PM, Serge E. Hallyn wrote:
>
> Quoting Mahesh Bandewar (mah...@bandewar.net):
> > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> > that belongs to uncontrolled user-ns can create another (child) user-
> > namespace that is uncontrolled. Any other
Quoting Mahesh Bandewar (mah...@bandewar.net):
> Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> that belongs to uncontrolled user-ns can create another (child) user-
> namespace that is uncontrolled. Any other process (that either does
> not have SYS_ADMIN or belongs to a co
From: Mahesh Bandewar
With this new notion of "controlled" user-namespaces, the controlled
user-namespaces are marked at the time of their creation while the
capabilities of processes that belong to them are controlled using the
global mask.
Init-user-ns is always uncontrolled and a process that
28 matches
Mail list logo
