[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jan 2017 19:14:11 +0000
From: Jessica Frazelle <me@...sfraz.com>
To: Kees Cook <keescook@...omium.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Introduction
Cool! Have already started looking into it! Super excited :D
On Thu, Jan 26, 2017 at 1:42 PM Kees Cook <keescook@...omium.org> wrote:
> 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
>
Content of type "text/html" skipped
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.
