>> The admin of such a machine could have disabled userns months earlier
>> and limited the scope of the attack.
>
> Of course for the paranoid there is already a mechanism to do this.
> /sbin/chroot.
>
> No new user namespaces are allowed to be created inside of a chroot.
Another alternative is t
On 2016-01-28 03:56, Serge E. Hallyn wrote:
On Mon, Jan 25, 2016 at 10:57:32PM -0600, Eric W. Biederman wrote:
What sounds like a generally useful feature that would cover your use
case and many others is a per user limit on the number of user
namespaces users may create.
Ok, I'm sorry, but af
On Mon, Jan 25, 2016 at 10:57:32PM -0600, Eric W. Biederman wrote:
> What sounds like a generally useful feature that would cover your use
> case and many others is a per user limit on the number of user
> namespaces users may create.
Ok, I'm sorry, but after thinking about this quite awhile, I th
On 2016-01-27 05:27, Eric W. Biederman wrote:
Kees Cook writes:
On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn wrote:
Quoting Josh Boyer (jwbo...@fedoraproject.org):
What you're saying is true for the "oh crap" case of a new userns
related CVE being found. However, there is the case where s
Kees Cook writes:
> On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn wrote:
>> Quoting Josh Boyer (jwbo...@fedoraproject.org):
>>> What you're saying is true for the "oh crap" case of a new userns
>>> related CVE being found. However, there is the case where sysadmins
>>> know for a fact that a se
On Tue, Jan 26, 2016 at 10:27 AM, Andy Lutomirski wrote:
> On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
> wrote:
>> On 2016-01-26 12:15, Serge Hallyn wrote:
>>>
>>> Quoting Josh Boyer (jwbo...@fedoraproject.org):
What you're saying is true for the "oh crap" case of a new userns
>>>
On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn wrote:
> Quoting Josh Boyer (jwbo...@fedoraproject.org):
>> What you're saying is true for the "oh crap" case of a new userns
>> related CVE being found. However, there is the case where sysadmins
>> know for a fact that a set of machines should not a
On 2016-01-26 14:56, Josh Boyer wrote:
On Tue, Jan 26, 2016 at 12:20 PM, Serge Hallyn wrote:
Quoting Josh Boyer (jwbo...@fedoraproject.org):
On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
wrote:
On 2016-01-26 09:38, Josh Boyer wrote:
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederm
On Tue, Jan 26, 2016 at 12:20 PM, Serge Hallyn wrote:
> Quoting Josh Boyer (jwbo...@fedoraproject.org):
>> On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
>> wrote:
>> > On 2016-01-26 09:38, Josh Boyer wrote:
>> >>
>> >> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
>> >> wrote:
>> >
On 2016-01-26 13:27, Andy Lutomirski wrote:
On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
wrote:
On 2016-01-26 12:15, Serge Hallyn wrote:
Quoting Josh Boyer (jwbo...@fedoraproject.org):
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
wrote:
Kees Cook writes:
On Mon, Jan 2
On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
wrote:
> On 2016-01-26 12:15, Serge Hallyn wrote:
>>
>> Quoting Josh Boyer (jwbo...@fedoraproject.org):
>>>
>>> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
>>> wrote:
Kees Cook writes:
> On Mon, Jan 25, 2016 at 11:
On 2016-01-26 12:15, Serge Hallyn wrote:
Quoting Josh Boyer (jwbo...@fedoraproject.org):
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
wrote:
Kees Cook writes:
On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
wrote:
Kees Cook writes:
Well, I don't know about less weird, but it
Quoting Josh Boyer (jwbo...@fedoraproject.org):
> On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
> wrote:
> > On 2016-01-26 09:38, Josh Boyer wrote:
> >>
> >> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
> >> wrote:
> >>>
> >>> Kees Cook writes:
> >>>
> On Mon, Jan 25, 2016 at
Quoting Josh Boyer (jwbo...@fedoraproject.org):
> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
> wrote:
> > Kees Cook writes:
> >
> >> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
> >> wrote:
> >>> Kees Cook writes:
>
> Well, I don't know about less weird, but it would l
On Mon, Jan 25, 2016 at 8:57 PM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>> wrote:
>>> Kees Cook writes:
Well, I don't know about less weird, but it would leave a unneeded
hole in the permission checks.
>>>
>>> To be c
On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
wrote:
> On 2016-01-26 09:38, Josh Boyer wrote:
>>
>> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
>> wrote:
>>>
>>> Kees Cook writes:
>>>
On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
wrote:
>
> Kees Cook wri
On 2016-01-26 09:38, Josh Boyer wrote:
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
wrote:
Kees Cook writes:
On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
wrote:
Kees Cook writes:
Well, I don't know about less weird, but it would leave a unneeded
hole in the permission chec
On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>> wrote:
>>> Kees Cook writes:
Well, I don't know about less weird, but it would leave a unneeded
hole in the permission checks.
>>>
>>> To be
Quoting Kees Cook (keesc...@chromium.org):
> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
> > So I have concerns about both efficacy and usability with the proposed
> > sysctl.
>
> Two distros already have this sysctl because it was so strongly
> requested by their users. This needs to be up
Kees Cook writes:
> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
> wrote:
>> Kees Cook writes:
>>>
>>> Well, I don't know about less weird, but it would leave a unneeded
>>> hole in the permission checks.
>>
>> To be clear the current patch has my:
>>
>> Nacked-by: "Eric W. Biederman"
>
> This feature is already implemented by two distros, and likely wanted
> by others. We cannot ignore that.
Date point: Arch Linux won't be enabling CONFIG_USERNS until there's a
way to disable unprivileged user namespaces. The kernel maintainers are
unwilling to carry long-term out-of-tree patche
On Mon, Jan 25, 2016 at 2:34 PM, Kees Cook wrote:
> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
> wrote:
>> Kees Cook writes:
>>>
>>> Well, I don't know about less weird, but it would leave a unneeded
>>> hole in the permission checks.
>>
>> To be clear the current patch has my:
>>
>> Na
On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
wrote:
> Kees Cook writes:
>>
>> Well, I don't know about less weird, but it would leave a unneeded
>> hole in the permission checks.
>
> To be clear the current patch has my:
>
> Nacked-by: "Eric W. Biederman"
>
> The code is buggy, and poorly
Kees Cook writes:
>
> Well, I don't know about less weird, but it would leave a unneeded
> hole in the permission checks.
To be clear the current patch has my:
Nacked-by: "Eric W. Biederman"
The code is buggy, and poorly thought through. Your lack of interest in
fixing the bugs in your patch
On Mon, Jan 25, 2016 at 10:53 AM, Andy Lutomirski wrote:
> On Mon, Jan 25, 2016 at 10:51 AM, Kees Cook wrote:
>> On Sun, Jan 24, 2016 at 2:22 PM, Andy Lutomirski wrote:
>>> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
>>> wrote:
Kees Cook writes:
> There continues to be une
On Mon, Jan 25, 2016 at 10:51 AM, Kees Cook wrote:
> On Sun, Jan 24, 2016 at 2:22 PM, Andy Lutomirski wrote:
>> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
>> wrote:
>>> Kees Cook writes:
>>>
There continues to be unexpected side-effects and security exposures
via CLONE_NEWUSER
On Sun, Jan 24, 2016 at 2:22 PM, Andy Lutomirski wrote:
> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
> wrote:
>> Kees Cook writes:
>>
>>> There continues to be unexpected side-effects and security exposures
>>> via CLONE_NEWUSER. For many end-users running distro kernels with
>>> CONFIG_
On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> There continues to be unexpected side-effects and security exposures
>> via CLONE_NEWUSER. For many end-users running distro kernels with
>> CONFIG_USER_NS enabled, there is no way to disable this feature when
>> d
On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> There continues to be unexpected side-effects and security exposures
>> via CLONE_NEWUSER. For many end-users running distro kernels with
>> CONFIG_USER_NS enabled, there is no way to disable this feature when
>> d
Kees Cook writes:
> There continues to be unexpected side-effects and security exposures
> via CLONE_NEWUSER. For many end-users running distro kernels with
> CONFIG_USER_NS enabled, there is no way to disable this feature when
> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER s
Am 22.01.2016 um 23:39 schrieb Kees Cook:
> There continues to be unexpected side-effects and security exposures
> via CLONE_NEWUSER. For many end-users running distro kernels with
> CONFIG_USER_NS enabled, there is no way to disable this feature when
> desired. As such, this creates a sysctl to re
31 matches
Mail list logo
