On Wed, Jan 9, 2013 at 6:29 PM, Lucas De Marchi
wrote:
> On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>>> Michael Kerrisk writes:
Hi Rusty,
>>>
>>> Hi Michael,
>>>
The
On Sun, Jan 6, 2013 at 4:59 PM, Michael Kerrisk (man-pages)
wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>> Michael Kerrisk writes:
>>> Hi Rusty,
>>
>> Hi Michael,
>>
>>> The description here is rather thin. Could you supply a sentence or
>>>
On Sun, Jan 6, 2013 at 9:24 PM, Kees Cook wrote:
> On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Rusty, (and Lucas, and Kees)
>>
>> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>>> Michael Kerrisk writes:
Hi Rusty,
>>>
>>> Hi Michael,
>>>
The desc
On Sun, Jan 6, 2013 at 11:59 AM, Michael Kerrisk (man-pages)
wrote:
> Hi Rusty, (and Lucas, and Kees)
>
> On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
>> Michael Kerrisk writes:
>>> Hi Rusty,
>>
>> Hi Michael,
>>
>>> The description here is rather thin. Could you supply a sentence or
>>>
Hi Rusty, (and Lucas, and Kees)
On Thu, Jan 3, 2013 at 1:12 AM, Rusty Russell wrote:
> Michael Kerrisk writes:
>> Hi Rusty,
>
> Hi Michael,
>
>> The description here is rather thin. Could you supply a sentence or
>> two for each of MODULE_INIT_IGNORE_MODVERSIONS and
>> MODULE_INIT_IGNORE_VERMAGI
Michael Kerrisk writes:
> Hi Rusty,
Hi Michael,
> The description here is rather thin. Could you supply a sentence or
> two for each of MODULE_INIT_IGNORE_MODVERSIONS and
> MODULE_INIT_IGNORE_VERMAGIC that would be suitable for the manual
> page?
>
> Thanks,
There are one or two safety checks b
Hi Rusty,
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I e
Kees Cook writes:
> Rusty,
>
> I haven't seen this land in your modules-next tree. I just wanted to
> make sure it hadn't gotten lost. I'd like to do some kmod tests
> against linux-next, but I've been waiting for this to appear.
Yes, sorting that out now, they should be in tomorrow's linux-next.
On Mon, Oct 22, 2012 at 12:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up wi
Lucas De Marchi writes:
> On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook wrote:
>> On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
>> wrote:
>>> sure... but do you realize this will fail in case kernel is checking
>>> module signature and we passed --force to modprobe (therefore mangled
>>> the dec
On Tue, Oct 23, 2012 at 1:42 PM, Kees Cook wrote:
> On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
> wrote:
>> On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
>>> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
>>> wrote:
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell
wrote:
>>
On 10/23/2012 08:42 AM, Kees Cook wrote:
Hm, yeah, userspace mangling of a module plus signing would fail.
Seems like mangling and signing aren't compatible. Doing it in
kernel-space (as now written for finit_module) solves that, but it
means that now compression isn't possible if you need both
On Mon, Oct 22, 2012 at 9:08 PM, Lucas De Marchi
wrote:
> On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
>> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
>> wrote:
>>> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell
>>> wrote:
"Michael Kerrisk (man-pages)" writes:
>> FIX: add fl
On Mon, Oct 22, 2012 at 9:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up wit
On Tue, Oct 23, 2012 at 1:40 AM, Kees Cook wrote:
> On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
> wrote:
>> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
>>> "Michael Kerrisk (man-pages)" writes:
> FIX: add flags arg to sys_finit_module()
>
> Thanks to Michael Kerrisk f
On Mon, Oct 22, 2012 at 7:37 PM, Lucas De Marchi
wrote:
> On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
>> "Michael Kerrisk (man-pages)" writes:
FIX: add flags arg to sys_finit_module()
Thanks to Michael Kerrisk for keeping us honest.
>>>
>>> w00t! Thanks, Rusty ;-).
>>>
>
On Mon, Oct 22, 2012 at 5:39 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>>> FIX: add flags arg to sys_finit_module()
>>>
>>> Thanks to Michael Kerrisk for keeping us honest.
>>
>> w00t! Thanks, Rusty ;-).
>>
>> Acked-by: Michael Kerrisk
>
> Here's the version I ended up wit
"Michael Kerrisk (man-pages)" writes:
>> FIX: add flags arg to sys_finit_module()
>>
>> Thanks to Michael Kerrisk for keeping us honest.
>
> w00t! Thanks, Rusty ;-).
>
> Acked-by: Michael Kerrisk
Here's the version I ended up with when I added two flags.
Lucas, is this useful to you?
BTW Micha
"H. Peter Anvin" writes:
> On 10/18/2012 07:23 PM, Rusty Russell wrote:
>> "H. Peter Anvin" writes:
>>> Given that, I have to say I now seriously question the value of
>>> finit_module(). The kernel can trivially discover if the pointed-to
>>> memory area is a MAP_SHARED mmap() of a file descrip
H. Peter Anvin zytor.com> writes:
> > It is a bit more indirect, but also in practice it's a bit trickier than
> > that. We need to ensure the memory doesn't change underneath us and
> > stays attached to that fd. I can easily see that code slipping and
> > ending in an exploit.
> >
> > But that
On 10/18/2012 07:23 PM, Rusty Russell wrote:
"H. Peter Anvin" writes:
Given that, I have to say I now seriously question the value of
finit_module(). The kernel can trivially discover if the pointed-to
memory area is a MAP_SHARED mmap() of a file descriptor and if so which
file descriptor... w
"H. Peter Anvin" writes:
> Given that, I have to say I now seriously question the value of
> finit_module(). The kernel can trivially discover if the pointed-to
> memory area is a MAP_SHARED mmap() of a file descriptor and if so which
> file descriptor... why can't we handle this behind the sc
On 10/18/2012 08:28 AM, Kees Cook wrote:
The goal for finit_module is to make sure we're getting what's on the
filesystem, not an arbitrary blob, so we can reason about it for
security policy.
Yes, I get that... although I'm starting to think that that might
actually be a really bad idea.
On Thu, Oct 18, 2012 at 7:26 AM, H. Peter Anvin wrote:
> On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
>>>
>>>
>>> So perhaps what we *should* have is something that points to the module
>>> to a (buffer, length) in userspace, and the equivalent of the current
>>> init_module() would
On 10/18/2012 01:05 AM, Michael Kerrisk (man-pages) wrote:
So perhaps what we *should* have is something that points to the module
to a (buffer, length) in userspace, and the equivalent of the current
init_module() would be open() + mmap() + minit_module() + close()?
So, I don't get it. What a
On Thu, Oct 18, 2012 at 5:12 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> Sure. But my point that started this subthread was: should we take the
>> opportunity now to add a 'flags' argument to the new finit_module()
>> system call, so as to allow flexibility in extending th
On Thu, Oct 18, 2012 at 6:24 AM, H. Peter Anvin wrote:
> On 10/11/2012 03:16 PM, Rusty Russell wrote:
>> "H. Peter Anvin" writes:
>>
>>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
Good point. A "whole hog" openat()-style interface is worth thinking about
too.
>>>
>>> *A
On Thu, Oct 18, 2012 at 12:12 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> Sure. But my point that started this subthread was: should we take the
>> opportunity now to add a 'flags' argument to the new finit_module()
>> system call, so as to allow flexibility in extending t
On 10/11/2012 03:16 PM, Rusty Russell wrote:
> "H. Peter Anvin" writes:
>
>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>>> Good point. A "whole hog" openat()-style interface is worth thinking about
>>> too.
>>
>> *Although* you could argue that you can always simply open the mod
"Michael Kerrisk (man-pages)" writes:
> Sure. But my point that started this subthread was: should we take the
> opportunity now to add a 'flags' argument to the new finit_module()
> system call, so as to allow flexibility in extending the behavior in
> future? There have been so many cases of rev
Rusty,
On Fri, Oct 12, 2012 at 12:16 AM, Rusty Russell wrote:
> "H. Peter Anvin" writes:
>
>> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>>> Good point. A "whole hog" openat()-style interface is worth thinking about
>>> too.
>>
>> *Although* you could argue that you can always s
"H. Peter Anvin" writes:
> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
>> Good point. A "whole hog" openat()-style interface is worth thinking about
>> too.
>
> *Although* you could argue that you can always simply open the module
> file first, and that finit_module() is really wh
[resending because my mobile device decided it
wanted to send HTML, which of course bounced.]
On Oct 10, 2012 12:09 AM, "H. Peter Anvin" wrote:
>
> On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
> > Good point. A "whole hog" openat()-style interface is worth thinking about
> > too.
>
On 10/10/2012 06:03 AM, Michael Kerrisk (man-pages) wrote:
> Good point. A "whole hog" openat()-style interface is worth thinking about
> too.
*Although* you could argue that you can always simply open the module
file first, and that finit_module() is really what we should have had in
the first p
On Tue, Oct 9, 2012 at 11:58 PM, H. Peter Anvin wrote:
> On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
>> Kees,
>>
>>> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
>>
>> Given the repeated experience of the last few years--new system calls
>> that are in essence revisions o
On 10/10/2012 05:54 AM, Michael Kerrisk wrote:
> Kees,
>
>> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
>
> Given the repeated experience of the last few years--new system calls
> that are in essence revisions of older system calls with a 'flags'
> argument bolted on to al
Kees,
> +SYSCALL_DEFINE2(finit_module, int, fd, const char __user *, uargs)
Given the repeated experience of the last few years--new system calls
that are in essence revisions of older system calls with a 'flags'
argument bolted on to allow more flexible behavior (e.g., accept4(),
dup3(), utimens
Mimi Zohar writes:
> Why? Not only have you had these patches sitting for a while, way
> before you had the kernel module patches, they've been acked/signed off
> by Kees, Serge, Eric, and myself. All security subtree maintainers.
> The module patches could have easily been built on top of Kees'
On Thu, Oct 4, 2012 at 8:50 PM, Rusty Russell wrote:
> Mimi Zohar writes:
>> Why? Not only have you had these patches sitting for a while, way
>> before you had the kernel module patches, they've been acked/signed off
>> by Kees, Serge, Eric, and myself. All security subtree maintainers.
>> The
On Wed, Oct 3, 2012 at 10:39 PM, Rusty Russell wrote:
> Kees Cook writes:
>
>> On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
>>> As part of the effort to create a stronger boundary between root and
>>> kernel, Chrome OS wants to be able to enforce that kernel modules are
>>> being loaded onl
On Thu, 2012-10-04 at 15:09 +0930, Rusty Russell wrote:
> Kees Cook writes:
>
> > On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
> >> As part of the effort to create a stronger boundary between root and
> >> kernel, Chrome OS wants to be able to enforce that kernel modules are
> >> being load
Kees Cook writes:
> On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
>> As part of the effort to create a stronger boundary between root and
>> kernel, Chrome OS wants to be able to enforce that kernel modules are
>> being loaded only from our read-only crypto-hash verified (dm_verity)
>> root
On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote:
> As part of the effort to create a stronger boundary between root and
> kernel, Chrome OS wants to be able to enforce that kernel modules are
> being loaded only from our read-only crypto-hash verified (dm_verity)
> root filesystem. Since the init
On 09/20/2012 07:22 PM, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
>> Earlier proposals for appending signatures to kernel modules would not be
>> useful in Chrome OS, since it would involve adding an additional set of
>> keys to our kernel and builds for no good reason: we alre
On Fri, 2012-09-21 at 12:22 +1000, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
> > Earlier proposals for appending signatures to kernel modules would not be
> > useful in Chrome OS, since it would involve adding an additional set of
> > keys to our kernel and builds for no good r
On Thu, Sep 20, 2012 at 7:22 PM, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
>> Earlier proposals for appending signatures to kernel modules would not be
>> useful in Chrome OS, since it would involve adding an additional set of
>> keys to our kernel and builds for no good reason
On Thu, 20 Sep 2012, Kees Cook wrote:
> Earlier proposals for appending signatures to kernel modules would not be
> useful in Chrome OS, since it would involve adding an additional set of
> keys to our kernel and builds for no good reason: we already trust the
> contents of our root filesystem. We
47 matches
Mail list logo
