Date: Thu, 26 Jan 2017 13:42:20 -0800 From: Kees Cook <keescook@...omium.org> To: Jessica Frazelle <me@...sfraz.com> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: Introduction On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@...sfraz.com> wrote: > On Wed, Jan 25, 2017, 11:37 Kees Cook <keescook@...omium.org> wrote: >> >> On Mon, Jan 23, 2017 at 4:06 PM, Jessica Frazelle <me@...sfraz.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.