[kernel-hardening] Introduction

[kernel-hardening] Introduction

[park jinbum]

Hello All,

I'd like to contribute to kernel self protection project.
I've experienced ARM kernel, security solution on production.
(kernel memory protection, contents protection, ...)

I'm interested in following topics.
- Move kernel stack to vmap area (done on x86, other archs still need it)
- KASLR for ARM
- protect ARM vector table as fixed-location kernel target
- expand use of __ro_after_init, especially in arch/arm64

I'm still a kernel newbie,  so they can be too much for me.
If there is something easier and smaller to do, that is good for me.

Re: [kernel-hardening] Introduction

[Mark Rutland]

On Fri, Jan 13, 2017 at 12:06:31AM +0900, park jinbum wrote:
> Hello All,

Hi,

> I'd like to contribute to kernel self protection project.
> I've experienced ARM kernel, security solution on production.
> (kernel memory protection, contents protection, ...)
> 
> I'm interested in following topics.
> - Move kernel stack to vmap area (done on x86, other archs still need it)

FWIW, I'm looking at this for arm64 (and Takahiro-san is also looking at
this area). Making the stacks virtually mapped is fairly trivial, but
implementing reliable {under,over}flow handling is fairly involved.

32-bit ARM is also somewhat starved for vmalloc space, so ignoring the
difficulties in exception handling changes, I'm not sure that's going to
be widely deployable.

I believe it should be possible to implement THREAD_INFO_IN_TASK for arm
similarly to arm64, which would bring some benefit regardless.

Takahiro-san, were you looking into that at all?

> - KASLR for ARM

Given the small amount of VA space on 32-bit, and the potential of
kernel addresses to be determined by other means, I'm not sure that
there's much gain from this relative to the work involved.

> - protect ARM vector table as fixed-location kernel target

I'm not exactly sure what this means (I see it was taken from the KSPP
todo list?). Kees -- did you have a specific idea here?

On cores with VBAR, the vectors can be moved, so it might be possible to
dynamically allocate them at a random position. Otherwise, I was under
the impression that this was RO with DEBUG_RODATA selected.

... on that note, mandating DEBUG_RODATA for 32-bit ARM would be a good
step forward.

Thanks,
Mark.

Re: [kernel-hardening] Introduction

[AKASHI, Takahiro]

On Thu, Jan 12, 2017 at 04:06:02PM +0000, Mark Rutland wrote:
> On Fri, Jan 13, 2017 at 12:06:31AM +0900, park jinbum wrote:
> > Hello All,
> 
> Hi,
> 
> > I'd like to contribute to kernel self protection project.
> > I've experienced ARM kernel, security solution on production.
> > (kernel memory protection, contents protection, ...)
> > 
> > I'm interested in following topics.
> > - Move kernel stack to vmap area (done on x86, other archs still need it)
> 
> FWIW, I'm looking at this for arm64 (and Takahiro-san is also looking at
> this area). Making the stacks virtually mapped is fairly trivial, but
> implementing reliable {under,over}flow handling is fairly involved.
> 
> 32-bit ARM is also somewhat starved for vmalloc space, so ignoring the
> difficulties in exception handling changes, I'm not sure that's going to
> be widely deployable.
> 
> I believe it should be possible to implement THREAD_INFO_IN_TASK for arm
> similarly to arm64, which would bring some benefit regardless.
> 
> Takahiro-san, were you looking into that at all?

No, never.
I'm currently taking a quick look at PAX_MEMORY_STACKLEAK and
PAX_MEMORY_STRUCTLEAK (on both arm64 and x86 though arch-specific
portion of code is quite small).

-Takahiro AKASHI

> > - KASLR for ARM
> 
> Given the small amount of VA space on 32-bit, and the potential of
> kernel addresses to be determined by other means, I'm not sure that
> there's much gain from this relative to the work involved.
> 
> > - protect ARM vector table as fixed-location kernel target
> 
> I'm not exactly sure what this means (I see it was taken from the KSPP
> todo list?). Kees -- did you have a specific idea here?
> 
> On cores with VBAR, the vectors can be moved, so it might be possible to
> dynamically allocate them at a random position. Otherwise, I was under
> the impression that this was RO with DEBUG_RODATA selected.
> 
> ... on that note, mandating DEBUG_RODATA for 32-bit ARM would be a good
> step forward.
> 
> Thanks,
> Mark.

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 12:23 AM, AKASHI, Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Thu, Jan 12, 2017 at 04:06:02PM +0000, Mark Rutland wrote:
>> On Fri, Jan 13, 2017 at 12:06:31AM +0900, park jinbum wrote:
>> > Hello All,
>>
>> Hi,
>>
>> > I'd like to contribute to kernel self protection project.
>> > I've experienced ARM kernel, security solution on production.
>> > (kernel memory protection, contents protection, ...)
>> >
>> > I'm interested in following topics.
>> > - Move kernel stack to vmap area (done on x86, other archs still need it)
>>
>> FWIW, I'm looking at this for arm64 (and Takahiro-san is also looking at
>> this area). Making the stacks virtually mapped is fairly trivial, but
>> implementing reliable {under,over}flow handling is fairly involved.
>>
>> 32-bit ARM is also somewhat starved for vmalloc space, so ignoring the
>> difficulties in exception handling changes, I'm not sure that's going to
>> be widely deployable.
>>
>> I believe it should be possible to implement THREAD_INFO_IN_TASK for arm
>> similarly to arm64, which would bring some benefit regardless.
>>
>> Takahiro-san, were you looking into that at all?
>
> No, never.
> I'm currently taking a quick look at PAX_MEMORY_STACKLEAK and
> PAX_MEMORY_STRUCTLEAK (on both arm64 and x86 though arch-specific
> portion of code is quite small).

I've spent a little time looking at STRUCTLEAK -- it shouldn't be too
hard to upstream (I have it extracted in one of my trees).

PaX Team, the heuristic for STRUCTLEAK appears to be "does the struct
contain anything marked __user". Is this actually a meaningful
information exposure case? It seems like there are a lot more cases
for exposures where there is nothing marked __user. Is that the
meaning of "much smaller coverage" compared to STACKLEAK in the
Kconfig?

Very little in my build testing actually triggered the "userspace
variable will be forcibly initialized" warning from the plugin, but
perhaps I didn't port something correctly.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[PaX Team]

On 13 Jan 2017 at 9:54, Kees Cook wrote:

> PaX Team, the heuristic for STRUCTLEAK appears to be "does the struct
> contain anything marked __user". Is this actually a meaningful
> information exposure case? It seems like there are a lot more cases
> for exposures where there is nothing marked __user. Is that the
> meaning of "much smaller coverage" compared to STACKLEAK in the
> Kconfig?

STRUCTLEAK was written in response to a particular bug a few years ago
where we didn't want to give the bug away but still wanted to fix it
during the embargo. the struct in question could be matched by this
heuristics, matching everything else (however little of it) is really
just a free side effect. could coverage be improved? of course but that
would take a whole lot more work (manual markups and/or data flow analysis
in LTO mode).

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@freemail.hu> wrote:
> On 13 Jan 2017 at 9:54, Kees Cook wrote:
>
>> PaX Team, the heuristic for STRUCTLEAK appears to be "does the struct
>> contain anything marked __user". Is this actually a meaningful
>> information exposure case? It seems like there are a lot more cases
>> for exposures where there is nothing marked __user. Is that the
>> meaning of "much smaller coverage" compared to STACKLEAK in the
>> Kconfig?
>
> STRUCTLEAK was written in response to a particular bug a few years ago
> where we didn't want to give the bug away but still wanted to fix it
> during the embargo. the struct in question could be matched by this
> heuristics, matching everything else (however little of it) is really
> just a free side effect. could coverage be improved? of course but that
> would take a whole lot more work (manual markups and/or data flow analysis
> in LTO mode).

Out of curiosity, do you remember which bug? I'd be curious to compare
it against others. It seems like adding structleak to upstream still
has value, even if the coverage isn't as complete as stackleak.

I wanted to do some simple performance checks with it too. I imagine
it wouldn't have much impact given its coverage isn't very wide.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 11:06 AM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@freemail.hu> wrote:
>> On 13 Jan 2017 at 9:54, Kees Cook wrote:
>>
>>> PaX Team, the heuristic for STRUCTLEAK appears to be "does the struct
>>> contain anything marked __user". Is this actually a meaningful
>>> information exposure case? It seems like there are a lot more cases
>>> for exposures where there is nothing marked __user. Is that the
>>> meaning of "much smaller coverage" compared to STACKLEAK in the
>>> Kconfig?
>>
>> STRUCTLEAK was written in response to a particular bug a few years ago
>> where we didn't want to give the bug away but still wanted to fix it
>> during the embargo. the struct in question could be matched by this
>> heuristics, matching everything else (however little of it) is really
>> just a free side effect. could coverage be improved? of course but that
>> would take a whole lot more work (manual markups and/or data flow analysis
>> in LTO mode).
>
> Out of curiosity, do you remember which bug? I'd be curious to compare
> it against others. It seems like adding structleak to upstream still
> has value, even if the coverage isn't as complete as stackleak.
>
> I wanted to do some simple performance checks with it too. I imagine
> it wouldn't have much impact given its coverage isn't very wide.

I did notice too that it seems like it doesn't notice static initializers:

security/tomoyo/common.c: In function ‘tomoyo_load_builtin_policy’:
security/tomoyo/common.c:2745:27: note: userspace variable will be
forcibly initialized
   struct tomoyo_io_buffer head = { };
                           ^

fs/read_write.c: In function ‘new_sync_write’:
fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
  struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
               ^

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[PaX Team]

On 13 Jan 2017 at 11:06, Kees Cook wrote:

> Out of curiosity, do you remember which bug? I'd be curious to compare
> it against others. It seems like adding structleak to upstream still
> has value, even if the coverage isn't as complete as stackleak.

i think it was CVE-2013-2141 where siginfo has at least one __user ptr field.

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 11:26 AM, Kees Cook <keescook@chromium.org> wrote:
> I did notice too that it seems like it doesn't notice static initializers:
>
> security/tomoyo/common.c: In function ‘tomoyo_load_builtin_policy’:
> security/tomoyo/common.c:2745:27: note: userspace variable will be
> forcibly initialized
>    struct tomoyo_io_buffer head = { };
>                            ^
>
> fs/read_write.c: In function ‘new_sync_write’:
> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
>                ^

If I dump the gimple, it looks like the assignments aren't being
marked as CONSTRUTOR?

fs/read_write.c: In function ‘new_sync_read’:
fs/read_write.c:433:15: note: userspace variable will be forcibly initialized
  struct iovec iov = { .iov_base = buf, .iov_len = len };
               ^
# .MEM_3 = VDEF <.MEM_1(D)>
iov.iov_base = buf_2(D);
# .MEM_5 = VDEF <.MEM_3>
iov.iov_len = len_4(D);
...

Hmmm

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[Daniel Micay]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

On Fri, 2017-01-13 at 11:06 -0800, Kees Cook wrote:
> On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@freemail.hu>
> wrote:
> > On 13 Jan 2017 at 9:54, Kees Cook wrote:
> > 
> > > PaX Team, the heuristic for STRUCTLEAK appears to be "does the
> > > struct
> > > contain anything marked __user". Is this actually a meaningful
> > > information exposure case? It seems like there are a lot more
> > > cases
> > > for exposures where there is nothing marked __user. Is that the
> > > meaning of "much smaller coverage" compared to STACKLEAK in the
> > > Kconfig?
> > 
> > STRUCTLEAK was written in response to a particular bug a few years
> > ago
> > where we didn't want to give the bug away but still wanted to fix it
> > during the embargo. the struct in question could be matched by this
> > heuristics, matching everything else (however little of it) is
> > really
> > just a free side effect. could coverage be improved? of course but
> > that
> > would take a whole lot more work (manual markups and/or data flow
> > analysis
> > in LTO mode).
> 
> Out of curiosity, do you remember which bug? I'd be curious to compare
> it against others. It seems like adding structleak to upstream still
> has value, even if the coverage isn't as complete as stackleak.

There's the performance-oblivious approach of zeroing all locals early
in the compiler pipeline and relying on compiler optimizations to remove
it when it's not required. They're already pretty good at doing it.
There can be a scale of aggressiveness for a feature like this, with
very conservative heuristics on one end (like analysis to propagate from
copy_to_user) and no heuristics at all for the other. It would be
interesting to measure that to figure out the worst case performance
scenario, particularly if it's possible to narrow down areas where it
hurts and then work out some simple heuristics to reduce the cost. Maybe
most of the cost can be alleviated by not doing arrays or by having a
size limit, etc. Maybe there are only a few areas where it really hurts
and they could be marked. Need to test before conclusions about
heuristics can be drawn.

I'm doing it for Android's userspace via Clang. It's usually very cheap
and actually costs less than SSP for most code. The top of the stack is
inherently hot data and since it's not adding branches, the main cost is
probably code size. There are some cases where it can really hurt due to
arrays on the stack, but the kernel doesn't have as many of those
particularly with large arrays. I haven't implemented it for GCC so I
haven't had a chance to try it with the kernel yet. I expect it to be
more than cheap enough for my needs though.

If nothing else, it could be a useful way to uncover bugs via the option
of a non-zero byte value for debug builds rather than the production
oriented zeroing. AFAIK, the kernel doesn't have anything to do that on
the stack, and I haven't had much luck with MSan in userspace anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 1:57 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Fri, 2017-01-13 at 11:06 -0800, Kees Cook wrote:
>> On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@freemail.hu>
>> wrote:
>> > On 13 Jan 2017 at 9:54, Kees Cook wrote:
>> >
>> > > PaX Team, the heuristic for STRUCTLEAK appears to be "does the
>> > > struct
>> > > contain anything marked __user". Is this actually a meaningful
>> > > information exposure case? It seems like there are a lot more
>> > > cases
>> > > for exposures where there is nothing marked __user. Is that the
>> > > meaning of "much smaller coverage" compared to STACKLEAK in the
>> > > Kconfig?
>> >
>> > STRUCTLEAK was written in response to a particular bug a few years
>> > ago
>> > where we didn't want to give the bug away but still wanted to fix it
>> > during the embargo. the struct in question could be matched by this
>> > heuristics, matching everything else (however little of it) is
>> > really
>> > just a free side effect. could coverage be improved? of course but
>> > that
>> > would take a whole lot more work (manual markups and/or data flow
>> > analysis
>> > in LTO mode).
>>
>> Out of curiosity, do you remember which bug? I'd be curious to compare
>> it against others. It seems like adding structleak to upstream still
>> has value, even if the coverage isn't as complete as stackleak.
>
> There's the performance-oblivious approach of zeroing all locals early
> in the compiler pipeline and relying on compiler optimizations to remove
> it when it's not required. They're already pretty good at doing it.

Yeah, I think that's what happens here. Some initializations are seen
as constructors still, while others are marked as SSAs already.
Hopefully the optimization pass will correctly collapse the cases.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[PaX Team]

On 13 Jan 2017 at 11:26, Kees Cook wrote:

> I did notice too that it seems like it doesn't notice static initializers:
>
> security/tomoyo/common.c: In function ‘tomoyo_load_builtin_policy’:
> security/tomoyo/common.c:2745:27: note: userspace variable will be
> forcibly initialized
>    struct tomoyo_io_buffer head = { };

in this case the variable (and its initializer) is in a loop scope (not
the function scope), so it's not matched. as i said, the plugin was written
to match a specific situation, not everything under the sun ;). now it's
possible to extend the coverage to loops as well, but then you'll have to
be careful with performance impact as more and more code will match and
inside a loop the impact can quickly add up...

> fs/read_write.c: In function ‘new_sync_write’:
> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };

this is a designated initializer which doesn't match the object constructor
the plugin looks for.

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 13, 2017 at 3:09 PM, PaX Team <pageexec@freemail.hu> wrote:
>> fs/read_write.c: In function ‘new_sync_write’:
>> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
>>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
>
> this is a designated initializer which doesn't match the object constructor
> the plugin looks for.

What would an object constructor look like? When I had it report the
times it skipped forced initialization, the code mostly looked like
designated initializers. All I found in the gimple were SSAs. Nothing
jumped out at me as being an initializer.

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[PaX Team]

On 13 Jan 2017 at 15:15, Kees Cook wrote:

> On Fri, Jan 13, 2017 at 3:09 PM, PaX Team <pageexec@freemail.hu> wrote:
> >> fs/read_write.c: In function ‘new_sync_write’:
> >> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
> >>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
> >
> > this is a designated initializer which doesn't match the object constructor
> > the plugin looks for.
>
> What would an object constructor look like?

as you can see it in the plugin source, it has a specific TREE_CODE.

> When I had it report the times it skipped forced initialization, the
> code mostly looked like designated initializers. All I found in the
> gimple were SSAs. Nothing jumped out at me as being an initializer.

while the gimple dumps are human readable, they omit lots of information
so it's better to look at the data structures at compile time. that said,
a constructor should appear as an assignment like this:

  s1 = {};

a designated initializer is modeled as a constructor and per-field assignments
by the compiler (both are subject to optimizations so you won't necessarily see
all of them in the dumps of later passes).

Re: [kernel-hardening] Introduction

[Kees Cook]

On Sat, Jan 14, 2017 at 2:10 AM, PaX Team <pageexec@freemail.hu> wrote:
> On 13 Jan 2017 at 15:15, Kees Cook wrote:
>
>> On Fri, Jan 13, 2017 at 3:09 PM, PaX Team <pageexec@freemail.hu> wrote:
>> >> fs/read_write.c: In function ‘new_sync_write’:
>> >> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
>> >>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
>> >
>> > this is a designated initializer which doesn't match the object constructor
>> > the plugin looks for.
>>
>> What would an object constructor look like?
>
> as you can see it in the plugin source, it has a specific TREE_CODE.

Right, I meant on the C side. The gimple get produced several ways, it
seems, and it wasn't clear under which conditions it spat out a
constructor vs individual assignments.

>> When I had it report the times it skipped forced initialization, the
>> code mostly looked like designated initializers. All I found in the
>> gimple were SSAs. Nothing jumped out at me as being an initializer.
>
> while the gimple dumps are human readable, they omit lots of information
> so it's better to look at the data structures at compile time. that said,
> a constructor should appear as an assignment like this:
>
>   s1 = {};

Yup, saw that for the constructor that got injected.

> a designated initializer is modeled as a constructor and per-field assignments
> by the compiler (both are subject to optimizations so you won't necessarily see
> all of them in the dumps of later passes).

It sounds like the plugin would need to walk every field of the target
variable and check that it got an assignment.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[PaX Team]

On 17 Jan 2017 at 9:32, Kees Cook wrote:

> On Sat, Jan 14, 2017 at 2:10 AM, PaX Team <pageexec@freemail.hu> wrote:
> > On 13 Jan 2017 at 15:15, Kees Cook wrote:
> >
> >> On Fri, Jan 13, 2017 at 3:09 PM, PaX Team <pageexec@freemail.hu> wrote:
> >> >> fs/read_write.c: In function ‘new_sync_write’:
> >> >> fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
> >> >>   struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
> >> >
> >> > this is a designated initializer which doesn't match the object constructor
> >> > the plugin looks for.
> >>
> >> What would an object constructor look like?
> >
> > as you can see it in the plugin source, it has a specific TREE_CODE.
>
> Right, I meant on the C side. The gimple get produced several ways, it
> seems, and it wasn't clear under which conditions it spat out a
> constructor vs individual assignments.

it's what your example shows, a normal variable initialization. the reason
it's not a constructor in gcc is due to the C rule that we've been discussing
in another sub-thread: a full object initializer doesn't have to care about
padding and thus gcc in such cases omits the "= {}" constructor and only does
per-field assignments as described by the initializer. you could say that the
plugin could detect this case but then it'd also have to take into account
whether the type in question has padding, etc. like i said, there're many ways
to refine the pattern matching.

> > a designated initializer is modeled as a constructor and per-field assignments
> > by the compiler (both are subject to optimizations so you won't necessarily see
> > all of them in the dumps of later passes).
>
> It sounds like the plugin would need to walk every field of the target
> variable and check that it got an assignment.

yes, that's the kind of data flow analysis that can discover these assignments
and take them into account when deciding about forced initialization.

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Jan 27, 2017 at 11:14 AM, Jessica Frazelle <me@jessfraz.com> wrote:
> Cool! Have already started looking into it! Super excited :D
>
> On Thu, Jan 26, 2017 at 1:42 PM Kees Cook <keescook@chromium.org> wrote:
>>
>> On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@jessfraz.com> wrote:
>> > Honestly I'm open to working on whatever no one else wants too :)
>>
>> You said the magic words! ;) Looking at the TODO, I'll pick this
>> semi-randomly:
>>
>> - expand use of __ro_after_init, especially in arch/arm64
>>
>> It'd be nice to look through arch/arm64 to find anything that is close
>> to be able to be declared as const, but can't due to some post-boot
>> but pre-init changes. This is needs some manual examination currently,
>> but you can look at other uses of __ro_after_init in arch/x86 and
>> arch/arm. Of course, there's no reason to limit yourself to arch/arm64
>> if you find similar things in the core kernel code too.

I had someone point out that the IRQ subsystem has a lot of ops-type
structures that could be either const or __ro_after_init, for example
msi_domain_ops. That might be another area to look at.

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] Introduction

[Jessica Frazelle]

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]

Cool! Have already started looking into it! Super excited :D

On Thu, Jan 26, 2017 at 1:42 PM Kees Cook <keescook@chromium.org> wrote:

> On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@jessfraz.com> wrote:
> > On Wed, Jan 25, 2017, 11:37 Kees Cook <keescook@chromium.org> wrote:
> >>
> >> On Mon, Jan 23, 2017 at 4:06 PM, Jessica Frazelle <me@jessfraz.com>
> wrote:
> >> > I've been lurking on this mailing list for over a year now, so I think
> >> > I understand the gist of how it works. I am looking for some ways to
> >> > help out in my free time.
> >>
> >> Greetings! Thanks for saying "hi". :)
> >>
> >> > The subsystems I know the most about are cgroups and namespaces. I
> >> > previously was a maintainer of Docker (I added the seccomp integration
> >> > and maintained the AppArmor bits) and now I work on kubernetes.
> >> >
> >> > Let me know if you think there is a good place to start!
> >>
> >> I've mostly been trying to keep track of kernel self-protection TODO
> >> items, so I haven't been keeping too up to date on userspace-support
> >> things that the kernel provides. I know Solar has a list of things
> >> he'd like to see, and I know there was an earlier attempt at building
> >> an LSM to provide a more hardened chroot implementation (that Elena
> >> sent a version of last year).
> >>
> >
> > I am familiar with the chroot LSM from GRSEC, I'm not sure if this
> > would help containers much mostly because we use pivot_root and a lot
> > of that functionality can be reproduced by either capabilities
> > dropping or seccomp. I'm guessing it has a use outside containers but
> > I'm not really sure what that may be other than ease of use of not
> > having to drop caps etc. I am more than willing to help make sure it
> > gets done in a way everyone wants if that's the case.
> >
> >>
> >> Are there any gaps in existing cgroups/namespaces stuff that you'd
> >> like to see fixed? Or are there any areas of self-protection work that
> >> you find interesting and would want to learn more about?
> >>
> >> -Kees
> >>
> >> --
> >> Kees Cook
> >> Nexus Security
> >
> > I would definitely like to help with some mechanisms that containers
> > and others could integrate to become more secure and I have some ideas
> > for this, but they are kind of a larger scale feature.
> >
> > For now, I would love to help with whatever low hanging fruit no one
> > else wants to do but that might benefit some people. Then maybe once
> > I've been around the block enough times see if you all are interested
> > in something I have briefly thought of that maybe we could make
> > awesome together.
> >
> > Honestly I'm open to working on whatever no one else wants too :)
>
> You said the magic words! ;) Looking at the TODO, I'll pick this
> semi-randomly:
>
> - expand use of __ro_after_init, especially in arch/arm64
>
> It'd be nice to look through arch/arm64 to find anything that is close
> to be able to be declared as const, but can't due to some post-boot
> but pre-init changes. This is needs some manual examination currently,
> but you can look at other uses of __ro_after_init in arch/x86 and
> arch/arm. Of course, there's no reason to limit yourself to arch/arm64
> if you find similar things in the core kernel code too.
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
>

[-- Attachment #2: Type: text/html, Size: 5623 bytes --]

Re: [kernel-hardening] Introduction

[Kees Cook]

On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@jessfraz.com> wrote:
> On Wed, Jan 25, 2017, 11:37 Kees Cook <keescook@chromium.org> wrote:
>>
>> On Mon, Jan 23, 2017 at 4:06 PM, Jessica Frazelle <me@jessfraz.com> wrote:
>> > I've been lurking on this mailing list for over a year now, so I think
>> > I understand the gist of how it works. I am looking for some ways to
>> > help out in my free time.
>>
>> Greetings! Thanks for saying "hi". :)
>>
>> > The subsystems I know the most about are cgroups and namespaces. I
>> > previously was a maintainer of Docker (I added the seccomp integration
>> > and maintained the AppArmor bits) and now I work on kubernetes.
>> >
>> > Let me know if you think there is a good place to start!
>>
>> I've mostly been trying to keep track of kernel self-protection TODO
>> items, so I haven't been keeping too up to date on userspace-support
>> things that the kernel provides. I know Solar has a list of things
>> he'd like to see, and I know there was an earlier attempt at building
>> an LSM to provide a more hardened chroot implementation (that Elena
>> sent a version of last year).
>>
>
> I am familiar with the chroot LSM from GRSEC, I'm not sure if this
> would help containers much mostly because we use pivot_root and a lot
> of that functionality can be reproduced by either capabilities
> dropping or seccomp. I'm guessing it has a use outside containers but
> I'm not really sure what that may be other than ease of use of not
> having to drop caps etc. I am more than willing to help make sure it
> gets done in a way everyone wants if that's the case.
>
>>
>> Are there any gaps in existing cgroups/namespaces stuff that you'd
>> like to see fixed? Or are there any areas of self-protection work that
>> you find interesting and would want to learn more about?
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Nexus Security
>
> I would definitely like to help with some mechanisms that containers
> and others could integrate to become more secure and I have some ideas
> for this, but they are kind of a larger scale feature.
>
> For now, I would love to help with whatever low hanging fruit no one
> else wants to do but that might benefit some people. Then maybe once
> I've been around the block enough times see if you all are interested
> in something I have briefly thought of that maybe we could make
> awesome together.
>
> Honestly I'm open to working on whatever no one else wants too :)

You said the magic words! ;) Looking at the TODO, I'll pick this semi-randomly:

- expand use of __ro_after_init, especially in arch/arm64

It'd be nice to look through arch/arm64 to find anything that is close
to be able to be declared as const, but can't due to some post-boot
but pre-init changes. This is needs some manual examination currently,
but you can look at other uses of __ro_after_init in arch/x86 and
arch/arm. Of course, there's no reason to limit yourself to arch/arm64
if you find similar things in the core kernel code too.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Introduction

[Jessica Frazelle]

On Wed, Jan 25, 2017, 11:37 Kees Cook <keescook@chromium.org> wrote:
>
> On Mon, Jan 23, 2017 at 4:06 PM, Jessica Frazelle <me@jessfraz.com> wrote:
> > I've been lurking on this mailing list for over a year now, so I think
> > I understand the gist of how it works. I am looking for some ways to
> > help out in my free time.
>
> Greetings! Thanks for saying "hi". :)
>
> > The subsystems I know the most about are cgroups and namespaces. I
> > previously was a maintainer of Docker (I added the seccomp integration
> > and maintained the AppArmor bits) and now I work on kubernetes.
> >
> > Let me know if you think there is a good place to start!
>
> I've mostly been trying to keep track of kernel self-protection TODO
> items, so I haven't been keeping too up to date on userspace-support
> things that the kernel provides. I know Solar has a list of things
> he'd like to see, and I know there was an earlier attempt at building
> an LSM to provide a more hardened chroot implementation (that Elena
> sent a version of last year).
>

I am familiar with the chroot LSM from GRSEC, I'm not sure if this
would help containers much mostly because we use pivot_root and a lot
of that functionality can be reproduced by either capabilities
dropping or seccomp. I'm guessing it has a use outside containers but
I'm not really sure what that may be other than ease of use of not
having to drop caps etc. I am more than willing to help make sure it
gets done in a way everyone wants if that's the case.

>
> Are there any gaps in existing cgroups/namespaces stuff that you'd
> like to see fixed? Or are there any areas of self-protection work that
> you find interesting and would want to learn more about?
>
> -Kees
>
> --
> Kees Cook
> Nexus Security

I would definitely like to help with some mechanisms that containers
and others could integrate to become more secure and I have some ideas
for this, but they are kind of a larger scale feature.

For now, I would love to help with whatever low hanging fruit no one
else wants to do but that might benefit some people. Then maybe once
I've been around the block enough times see if you all are interested
in something I have briefly thought of that maybe we could make
awesome together.

Honestly I'm open to working on whatever no one else wants too :)

Re: [kernel-hardening] Introduction

[Kees Cook]

On Mon, Jan 23, 2017 at 4:06 PM, Jessica Frazelle <me@jessfraz.com> wrote:
> I've been lurking on this mailing list for over a year now, so I think
> I understand the gist of how it works. I am looking for some ways to
> help out in my free time.

Greetings! Thanks for saying "hi". :)

> The subsystems I know the most about are cgroups and namespaces. I
> previously was a maintainer of Docker (I added the seccomp integration
> and maintained the AppArmor bits) and now I work on kubernetes.
>
> Let me know if you think there is a good place to start!

I've mostly been trying to keep track of kernel self-protection TODO
items, so I haven't been keeping too up to date on userspace-support
things that the kernel provides. I know Solar has a list of things
he'd like to see, and I know there was an earlier attempt at building
an LSM to provide a more hardened chroot implementation (that Elena
sent a version of last year).

Are there any gaps in existing cgroups/namespaces stuff that you'd
like to see fixed? Or are there any areas of self-protection work that
you find interesting and would want to learn more about?

-Kees

-- 
Kees Cook
Nexus Security

[kernel-hardening] Introduction

[Jessica Frazelle]

I've been lurking on this mailing list for over a year now, so I think
I understand the gist of how it works. I am looking for some ways to
help out in my free time.

The subsystems I know the most about are cgroups and namespaces. I
previously was a maintainer of Docker (I added the seccomp integration
and maintained the AppArmor bits) and now I work on kubernetes.

Let me know if you think there is a good place to start!

Thanks,
Jess

Re: [kernel-hardening] Introduction

[Kees Cook]

On Fri, Dec 18, 2015 at 8:54 AM, Schaufler, Casey
<casey.schaufler@intel.com> wrote:
>> -----Original Message-----
>> From: Daniel Micay [mailto:danielmicay@gmail.com]
>> Sent: Thursday, December 17, 2015 4:49 PM
>> To: kernel-hardening@lists.openwall.com
>> Subject: Re: [kernel-hardening] Introduction
>>
>> On Thu, 2015-12-17 at 16:36 -0800, Kees Cook wrote:
>> > On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael
>> > <michael.leibowitz@intel.com> wrote:
>> > > I work in Intel's Open Source Technology center, along with my
>> > > colleague, Elena Reshetova.  I'm reasonably new real-life kernel
>> > > development, having previously just mucked about.  Otherwise, I'm a
>> > > long-time open source/security trouble maker.
>> >
>> > Hi! Welcome! :)
>> >
>> > > I'm Interested in working on struct randomization ala RANDSTRUCT.
>> > > Does this seem like a suitable task?
>> >
>> > I certainly wouldn't turn it down, but I would observe that it has
>> > some limited utility to users of the kernel that produce binary
>> > builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
>> > the same (though the next released version would see a different
>> > randomization, etc). It also complicates externally built modules. I
>> > see it depends on HIDESYM, though, which in turn depends on
>> > PAX_USERCOPY, so it would be much weaker without these two finished
>> > first.
>
> I'm working on teasing the PAX_USERCOPY implementation
> out of the greater grsecurity patch. I am reminded of a time
> when I had to pull a group of small splinters from my hand.
> Both for the difficulty in finding all of them, and the pain
> involved. I hope to have something limping along by the end
> of the month, holiday cheer permitting.

Fantastic! Thanks for taking a look at it.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

RE: [kernel-hardening] Introduction

[Schaufler, Casey]

> -----Original Message-----
> From: Daniel Micay [mailto:danielmicay@gmail.com]
> Sent: Thursday, December 17, 2015 4:49 PM
> To: kernel-hardening@lists.openwall.com
> Subject: Re: [kernel-hardening] Introduction
> 
> On Thu, 2015-12-17 at 16:36 -0800, Kees Cook wrote:
> > On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael
> > <michael.leibowitz@intel.com> wrote:
> > > I work in Intel's Open Source Technology center, along with my
> > > colleague, Elena Reshetova.  I'm reasonably new real-life kernel
> > > development, having previously just mucked about.  Otherwise, I'm a
> > > long-time open source/security trouble maker.
> >
> > Hi! Welcome! :)
> >
> > > I'm Interested in working on struct randomization ala RANDSTRUCT.
> > > Does this seem like a suitable task?
> >
> > I certainly wouldn't turn it down, but I would observe that it has
> > some limited utility to users of the kernel that produce binary
> > builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
> > the same (though the next released version would see a different
> > randomization, etc). It also complicates externally built modules. I
> > see it depends on HIDESYM, though, which in turn depends on
> > PAX_USERCOPY, so it would be much weaker without these two finished
> > first.

I'm working on teasing the PAX_USERCOPY implementation
out of the greater grsecurity patch. I am reminded of a time
when I had to pull a group of small splinters from my hand.
Both for the difficulty in finding all of them, and the pain
involved. I hope to have something limping along by the end
of the month, holiday cheer permitting.

Re: [kernel-hardening] Introduction

[David Windsor]

On Thu, Dec 17, 2015 at 7:36 PM, Kees Cook <keescook@chromium.org> wrote:

>
> Since there's no hardening tree yet, there's no maintainer, but since
> I'm trying to drive the kernel self-protection project here, I'll
> self-nominate myself as "hardening maintainer", FWIW. ;)
>

FWIW, I second this motion.

Thanks,
David

> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [kernel-hardening] Introduction

[Solar Designer]

On Thu, Dec 17, 2015 at 04:36:21PM -0800, Kees Cook wrote:
> On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael wrote:
> > I'm Interested in working on struct randomization ala RANDSTRUCT.
> > Does this seem like a suitable task?
> 
> I certainly wouldn't turn it down, but I would observe that it has
> some limited utility to users of the kernel that produce binary
> builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
> the same (though the next released version would see a different
> randomization, etc).

OTOH, it allows for a randomized-kernel-builds-as-a-service model, which
IIRC is something grsecurity was/is offering.  If the feature is
upstream'ed, perhaps there will be more setups of this sort, including
within a handful of organizations for their own use.

So I am in favor of Michael working on this feature.

> Since there's no hardening tree yet, there's no maintainer, but since
> I'm trying to drive the kernel self-protection project here, I'll
> self-nominate myself as "hardening maintainer", FWIW. ;)

I appreciate your effort on this, Kees!

Alexander

Re: [kernel-hardening] Introduction

[Daniel Micay]

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

On Thu, 2015-12-17 at 16:36 -0800, Kees Cook wrote:
> On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael
> <michael.leibowitz@intel.com> wrote:
> > I work in Intel's Open Source Technology center, along with my
> > colleague, Elena Reshetova.  I'm reasonably new real-life kernel
> > development, having previously just mucked about.  Otherwise, I'm a
> > long-time open source/security trouble maker.
> 
> Hi! Welcome! :)
> 
> > I'm Interested in working on struct randomization ala RANDSTRUCT.
> > Does this seem like a suitable task?
> 
> I certainly wouldn't turn it down, but I would observe that it has
> some limited utility to users of the kernel that produce binary
> builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
> the same (though the next released version would see a different
> randomization, etc). It also complicates externally built modules. I
> see it depends on HIDESYM, though, which in turn depends on
> PAX_USERCOPY, so it would be much weaker without these two finished
> first.
> 
> All that said, it might still be an interesting piece to extract. It
> would make automated cross-distro or cross-version attacks much more
> difficult to mount and has in the past exposed some bugs. (e.g.
> missing container_of() uses, etc.)

AFAIK spender was planning on implementing stack frame layout
randomization too (not sure if it's done yet) and that wouldn't have the
same ABI implications. They could be offered separately.

LLVM also has some code diversity stuff in progress like randomizing instruction scheduling to an extent (can at least determine any of the arbitrary decisions with random choices), and it would make sense for GCC too.

It can be more useful for builds distributions as binaries than it
seems. Making 256 or more builds with the tarballs padded out to the
same size and distributing them via encryption connections wouldn't be
difficult. It would be more difficult to implement for Android and
ChromeOS since they use delta updates but it could be done by having a
bunch of different release channels for each device. It might really
screw up delta updates if it's used across the system though, but the
kernel alone wouldn't be that bad.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Introduction

[Kees Cook]

On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael
<michael.leibowitz@intel.com> wrote:
> I work in Intel's Open Source Technology center, along with my
> colleague, Elena Reshetova.  I'm reasonably new real-life kernel
> development, having previously just mucked about.  Otherwise, I'm a
> long-time open source/security trouble maker.

Hi! Welcome! :)

> I'm Interested in working on struct randomization ala RANDSTRUCT.
> Does this seem like a suitable task?

I certainly wouldn't turn it down, but I would observe that it has
some limited utility to users of the kernel that produce binary
builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
the same (though the next released version would see a different
randomization, etc). It also complicates externally built modules. I
see it depends on HIDESYM, though, which in turn depends on
PAX_USERCOPY, so it would be much weaker without these two finished
first.

All that said, it might still be an interesting piece to extract. It
would make automated cross-distro or cross-version attacks much more
difficult to mount and has in the past exposed some bugs. (e.g.
missing container_of() uses, etc.)

> Also, what is the envisioned working model?  Is there a hardening tree
> to use?  Should we start with sending patches to this list?  Is there
> a hardening maintainer?

I think the most successful workflow for this kind of development is
to first coordinate on the list about what you want to tackle, nail
down what exploits or bug classes it addresses, then extract/create
it, develop tests, post for RFC, get some tuning, and then post it to
upstream for final vetting.

I'd prefer we develop against Linus's latest tree, though using the
prior release or -next is fine. Ultimately, it'll depend on the
maintainer's rebasing desires. Until we have actual dependencies,
there won't be a "hardened tree", though when it does happen, I expect
to be the one to build it from everyone's patch sets. For example, the
__ro_after_init tree lives here:
http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kspp/postinit-readonly

I think sending patches to the list early is a great idea. If you
don't have tests, we can help write them. If you're still looking for
good exploit examples, we can help hunt them down, etc. It'll let us
all fine-tune it and call out things that need fixing or improvement.
There's going to be a lot of bike-shedding, so best to get our
practice in now. :)

Since there's no hardening tree yet, there's no maintainer, but since
I'm trying to drive the kernel self-protection project here, I'll
self-nominate myself as "hardening maintainer", FWIW. ;)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[kernel-hardening] Introduction

[Leibowitz, Michael]

Hi,

I work in Intel's Open Source Technology center, along with my
colleague, Elena Reshetova.  I'm reasonably new real-life kernel
development, having previously just mucked about.  Otherwise, I'm a
long-time open source/security trouble maker.

I'm Interested in working on struct randomization ala RANDSTRUCT.
Does this seem like a suitable task?

Also, what is the envisioned working model?  Is there a hardening tree
to use?  Should we start with sending patches to this list?  Is there
a hardening maintainer?

Cheers

-- 
Michael Leibowitz