On Mon, Mar 4, 2013 at 10:21 AM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> On Mon, Mar 4, 2013 at 12:29 AM, Mathias Krause
>> wrote:
>>> On Sun, Mar 03, 2013 at 09:48:50AM -0800, Kees Cook wrote:
Several subsystems already have an implicit subsystem restriction
because they lo
Kees Cook writes:
> On Mon, Mar 4, 2013 at 12:29 AM, Mathias Krause
> wrote:
>> On Sun, Mar 03, 2013 at 09:48:50AM -0800, Kees Cook wrote:
>>> Several subsystems already have an implicit subsystem restriction
>>> because they load with aliases. (e.g. binfmt-, net-pf=NNN,
>>> snd-card-NNN, F
On Mon, Mar 4, 2013 at 12:29 AM, Mathias Krause wrote:
> On Sun, Mar 03, 2013 at 09:48:50AM -0800, Kees Cook wrote:
>> Several subsystems already have an implicit subsystem restriction
>> because they load with aliases. (e.g. binfmt-, net-pf=NNN,
>> snd-card-NNN, FOO-iosched, etc). This isn't
On Sun, Mar 03, 2013 at 09:48:50AM -0800, Kees Cook wrote:
> Several subsystems already have an implicit subsystem restriction
> because they load with aliases. (e.g. binfmt-, net-pf=NNN,
> snd-card-NNN, FOO-iosched, etc). This isn't the case for filesystems
> and a few others, unfortunately:
>
Kees Cook writes:
> On Sun, Mar 3, 2013 at 1:58 PM, Eric W. Biederman
> wrote:
> Ah-ha, thanks! Yes, that worked great. I think map_write()'s
> cap_valid/ns_capable calls confused me. :)
Yes permissions across user namespaces can be a little weird. But
mostly if you are their creator, you ar
On Sun, Mar 3, 2013 at 1:58 PM, Eric W. Biederman wrote:
> Kees Cook writes:
>
>> On Sat, Mar 2, 2013 at 8:12 PM, Eric W. Biederman
>> wrote:
>>> "Serge E. Hallyn" writes:
>>>
Quoting Kees Cook (keesc...@google.com):
> The rearranging done for user ns has resulted in allowing arbitrar
Kees Cook writes:
> On Sat, Mar 2, 2013 at 8:12 PM, Eric W. Biederman
> wrote:
>> "Serge E. Hallyn" writes:
>>
>>> Quoting Kees Cook (keesc...@google.com):
The rearranging done for user ns has resulted in allowing arbitrary
kernel module loading[1] (i.e. re-introducing a form of CVE-
On Sat, Mar 2, 2013 at 8:12 PM, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
>> Quoting Kees Cook (keesc...@google.com):
>>> The rearranging done for user ns has resulted in allowing arbitrary
>>> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
>>> by what is assu
On Sat, Mar 2, 2013 at 7:56 PM, Serge E. Hallyn wrote:
> Quoting Kees Cook (keesc...@google.com):
>> On Sat, Mar 2, 2013 at 4:57 PM, Serge E. Hallyn wrote:
>> > Quoting Kees Cook (keesc...@google.com):
>> >> The rearranging done for user ns has resulted in allowing arbitrary
>> >> kernel module l
"Serge E. Hallyn" writes:
> Quoting Kees Cook (keesc...@google.com):
>> The rearranging done for user ns has resulted in allowing arbitrary
>> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
>> by what is assumed to be an unprivileged process.
>>
>> At present, it does loo
Quoting Kees Cook (keesc...@google.com):
> On Sat, Mar 2, 2013 at 4:57 PM, Serge E. Hallyn wrote:
> > Quoting Kees Cook (keesc...@google.com):
> >> The rearranging done for user ns has resulted in allowing arbitrary
> >> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
> >> b
On Sat, Mar 2, 2013 at 4:57 PM, Serge E. Hallyn wrote:
> Quoting Kees Cook (keesc...@google.com):
>> The rearranging done for user ns has resulted in allowing arbitrary
>> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
>> by what is assumed to be an unprivileged process.
>>
Quoting Kees Cook (keesc...@google.com):
> The rearranging done for user ns has resulted in allowing arbitrary
> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
> by what is assumed to be an unprivileged process.
>
> At present, it does look to require at least CAP_SETUID al
13 matches
Mail list logo
