[kernel-hardening] Kernel Self Protection Project

[kernel-hardening] Kernel Self Protection Project

[Kees Cook]

I'm organizing a community of people to work on the various kernel
self-protection technologies (most of which are found in PaX and
Grsecurity). I'm building on the presentation I gave at Kernel Summit
where I sought to convince the other upstream Linux kernel developers
that security is more than fixing bugs, and that we need to bring in
proactive defenses:
http://lwn.net/Articles/662219/

This is especially highlighted by the Washington Post article today:
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/

Between the companies that recognize the critical nature of this work,
and with Linux Foundation's Core Infrastructure Initiative happy to
start funding specific work in this area, I think we can really make a
dent.

Let's start the work. I've built some wiki pages around my slides,
where we can take notes, list examples, and coordinate:
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
gcc plugin, which will also get us the gcc plugin infrastructure.
Other people, please speak up on what you'd like to tackle.

I recommend PAX_REFCOUNT, PAX_USERCOPY, and GRKERNSEC_KSTACKOVERFLOW
for some non-plugin stuff to look at.

Once we've got plugins, then we should look at PAX_MEMORY_STACKLEAK
and PAX_CONSTIFY_PLUGIN.

If you're feeling like disrupting people who depend on debugging, do
GRKERNSEC_HIDESYM.

If you're feeling especially bold, start on PAX_KERNEXEC and follow it
up with PAX_MEMORY_UDEREF.

Of course, there's plenty of other things, and tons I haven't listed
in the wiki -- please add them and bring them up for discussion here.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Kernel Self Protection Project

[David Windsor]

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

Hi,

I've done some work towards adding PAX_REFCOUNT to Ubuntu previously [1],
so I can resurrect those patches.  Note that those patches were directly
cherrypicked from PaX/grsec, without any sort of controls (sysctl, proc,
ioctl or otherwise) governing runtime behavior of this feature.  I can add
them if desired.

I also proposed a patch for adding overflow protection to kref [2], but
that patch was ultimately shot down.  Point being, I have some related
patches laying around that directly relate to refcount-based protection
which might be useful here.

Thanks,
David Windsor

[1]
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg3420821.html
[2] https://lkml.org/lkml/2012/2/24/331

On Thu, Nov 5, 2015 at 3:59 PM, Kees Cook <keescook@chromium.org> wrote:

> I'm organizing a community of people to work on the various kernel
> self-protection technologies (most of which are found in PaX and
> Grsecurity). I'm building on the presentation I gave at Kernel Summit
> where I sought to convince the other upstream Linux kernel developers
> that security is more than fixing bugs, and that we need to bring in
> proactive defenses:
> http://lwn.net/Articles/662219/
>
> This is especially highlighted by the Washington Post article today:
>
> http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/
>
> Between the companies that recognize the critical nature of this work,
> and with Linux Foundation's Core Infrastructure Initiative happy to
> start funding specific work in this area, I think we can really make a
> dent.
>
> Let's start the work. I've built some wiki pages around my slides,
> where we can take notes, list examples, and coordinate:
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
>
> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
> gcc plugin, which will also get us the gcc plugin infrastructure.
> Other people, please speak up on what you'd like to tackle.
>
> I recommend PAX_REFCOUNT, PAX_USERCOPY, and GRKERNSEC_KSTACKOVERFLOW
> for some non-plugin stuff to look at.
>
> Once we've got plugins, then we should look at PAX_MEMORY_STACKLEAK
> and PAX_CONSTIFY_PLUGIN.
>
> If you're feeling like disrupting people who depend on debugging, do
> GRKERNSEC_HIDESYM.
>
> If you're feeling especially bold, start on PAX_KERNEXEC and follow it
> up with PAX_MEMORY_UDEREF.
>
> Of course, there's plenty of other things, and tons I haven't listed
> in the wiki -- please add them and bring them up for discussion here.
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
>

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

Re: [kernel-hardening] Kernel Self Protection Project

[Kees Cook]

On Thu, Nov 5, 2015 at 1:14 PM, David Windsor <dave@0x4141.net> wrote:
> Hi,
>
> I've done some work towards adding PAX_REFCOUNT to Ubuntu previously [1], so
> I can resurrect those patches.  Note that those patches were directly
> cherrypicked from PaX/grsec, without any sort of controls (sysctl, proc,
> ioctl or otherwise) governing runtime behavior of this feature.  I can add
> them if desired.
>
> I also proposed a patch for adding overflow protection to kref [2], but that
> patch was ultimately shot down.  Point being, I have some related patches
> laying around that directly relate to refcount-based protection which might
> be useful here.

Yes, I remember this earlier attempt. Let's dust this off and try
again. If you could find some good examples of exploits this stops,
that could help people understand its purpose (if they don't
immediately see it to start with).

It might be nice to extract PAX_REFCOUNT as-is first, build tests for
it (for example, adding tests to CONFIG_LKDTM[1]), and then see what
about it needs polishing for it to go upstream (bikeshedding, docs,
sysctl, etc).

-Kees

[1] http://lwn.net/Articles/663531/

>
> Thanks,
> David Windsor
>
> [1]
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg3420821.html
> [2] https://lkml.org/lkml/2012/2/24/331
>
> On Thu, Nov 5, 2015 at 3:59 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> I'm organizing a community of people to work on the various kernel
>> self-protection technologies (most of which are found in PaX and
>> Grsecurity). I'm building on the presentation I gave at Kernel Summit
>> where I sought to convince the other upstream Linux kernel developers
>> that security is more than fixing bugs, and that we need to bring in
>> proactive defenses:
>> http://lwn.net/Articles/662219/
>>
>> This is especially highlighted by the Washington Post article today:
>>
>> http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/
>>
>> Between the companies that recognize the critical nature of this work,
>> and with Linux Foundation's Core Infrastructure Initiative happy to
>> start funding specific work in this area, I think we can really make a
>> dent.
>>
>> Let's start the work. I've built some wiki pages around my slides,
>> where we can take notes, list examples, and coordinate:
>> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
>>
>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>> gcc plugin, which will also get us the gcc plugin infrastructure.
>> Other people, please speak up on what you'd like to tackle.
>>
>> I recommend PAX_REFCOUNT, PAX_USERCOPY, and GRKERNSEC_KSTACKOVERFLOW
>> for some non-plugin stuff to look at.
>>
>> Once we've got plugins, then we should look at PAX_MEMORY_STACKLEAK
>> and PAX_CONSTIFY_PLUGIN.
>>
>> If you're feeling like disrupting people who depend on debugging, do
>> GRKERNSEC_HIDESYM.
>>
>> If you're feeling especially bold, start on PAX_KERNEXEC and follow it
>> up with PAX_MEMORY_UDEREF.
>>
>> Of course, there's plenty of other things, and tons I haven't listed
>> in the wiki -- please add them and bring them up for discussion here.
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Chrome OS Security
>
>



-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Kernel Self Protection Project

[Greg KH]

On Thu, Nov 05, 2015 at 04:14:22PM -0500, David Windsor wrote:
> I also proposed a patch for adding overflow protection to kref [2], but that
> patch was ultimately shot down.  Point being, I have some related patches
> laying around that directly relate to refcount-based protection which might be
> useful here. 

It was "shot down" because you crashed the system with your patch, which
isn't ok, it is a recoverable issue, and no one resent it in a version
that didn't do this.

Also, I'm not quite sure of what exactly you are trying to protect here
with a kref overflow patch, the threat-model you are going after was
never documented.

thanks,

greg k-h

Re: [kernel-hardening] Kernel Self Protection Project

[Yves-Alexis Perez]

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

On jeu., 2015-11-05 at 12:59 -0800, Kees Cook wrote:
> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
> gcc plugin, which will also get us the gcc plugin infrastructure.
> Other people, please speak up on what you'd like to tackle.

Hi Kees, and first many thanks for the initiative. That's definitely something
of interest for me (both personally and professionally).

Something which might also be interesting in kernel self protection is the
“active response” found in grsecurity (GRKERNSEC_SEC_KERN_LOCKOUT) and the
“deter exploite bruteforcing” (GRKERNSEC_BRUTE), which can help prevent
exploitation with repeated attempts.

Some features (especially SEC_KERN_LOCKOUT) are really more useful when UDEREF
and KERNEXEC are available (since those are the most severe violations one can
find), but it could still apply to other violations.

Regards,
-- 
Yves-Alexis


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

Re: [kernel-hardening] Kernel Self Protection Project

[Kees Cook]

On Fri, Nov 6, 2015 at 5:28 AM, Yves-Alexis Perez <corsac@debian.org> wrote:
> On jeu., 2015-11-05 at 12:59 -0800, Kees Cook wrote:
>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>> gcc plugin, which will also get us the gcc plugin infrastructure.
>> Other people, please speak up on what you'd like to tackle.
>
> Hi Kees, and first many thanks for the initiative. That's definitely something
> of interest for me (both personally and professionally).
>
> Something which might also be interesting in kernel self protection is the
> “active response” found in grsecurity (GRKERNSEC_SEC_KERN_LOCKOUT) and the
> “deter exploite bruteforcing” (GRKERNSEC_BRUTE), which can help prevent
> exploitation with repeated attempts.

I don't want to discourage work on any of this, but for now, I'm
trying to focus on kernel protections (rather than the userspace
hardening features). If other people (you?) want to coordinate the
userspace hardening work, then let's add it to the list, and create a
separate kernsec.org wiki landing place for it. I think it should be
organized in the same way, though: discuss a problem, give examples,
list potential mitigations.

FWIW, GRKERNSEC_BRUTE was attempted earlier[1], and the technical
discussion devolved into people thinking that glibc should handle it.
I totally disagree[2], since not all systems use glibc (Android).
Bruteforcing protection should be in the kernel: it is the manager of
processes, full stop.

> Some features (especially SEC_KERN_LOCKOUT) are really more useful when UDEREF
> and KERNEXEC are available (since those are the most severe violations one can
> find), but it could still apply to other violations.

I think GRKERNSEC_KERN_LOCKOUT is kind of on both sides of the
kernel/userspace defense fence. For now, I think the granularity of
response for KSPP-ported features will likely just be a full system
Oops. But I suspect once more of them land, we'll want the finer
granularity that GRKERNSEC_KERN_LOCKOUT provides.

-Kees

[1] https://lkml.org/lkml/2014/12/24/306
[2] https://lkml.org/lkml/2015/1/5/732

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Kernel Self Protection Project

[Richard Weinberger]

Am 06.11.2015 um 19:11 schrieb Kees Cook:
> On Fri, Nov 6, 2015 at 5:28 AM, Yves-Alexis Perez <corsac@debian.org> wrote:
>> On jeu., 2015-11-05 at 12:59 -0800, Kees Cook wrote:
>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>>> gcc plugin, which will also get us the gcc plugin infrastructure.
>>> Other people, please speak up on what you'd like to tackle.
>>
>> Hi Kees, and first many thanks for the initiative. That's definitely something
>> of interest for me (both personally and professionally).
>>
>> Something which might also be interesting in kernel self protection is the
>> “active response” found in grsecurity (GRKERNSEC_SEC_KERN_LOCKOUT) and the
>> “deter exploite bruteforcing” (GRKERNSEC_BRUTE), which can help prevent
>> exploitation with repeated attempts.
> 
> I don't want to discourage work on any of this, but for now, I'm
> trying to focus on kernel protections (rather than the userspace
> hardening features). If other people (you?) want to coordinate the
> userspace hardening work, then let's add it to the list, and create a
> separate kernsec.org wiki landing place for it. I think it should be
> organized in the same way, though: discuss a problem, give examples,
> list potential mitigations.
> 
> FWIW, GRKERNSEC_BRUTE was attempted earlier[1], and the technical
> discussion devolved into people thinking that glibc should handle it.
> I totally disagree[2], since not all systems use glibc (Android).
> Bruteforcing protection should be in the kernel: it is the manager of
> processes, full stop.

Thanks for bringing up my patch again.
Given the push back I've received (on and off list) I gave up.
But maybe it is time to try a second time. :-)

> [1] https://lkml.org/lkml/2014/12/24/306
> [2] https://lkml.org/lkml/2015/1/5/732

Thanks,
//richard

Re: [kernel-hardening] Kernel Self Protection Project

[Yves-Alexis Perez]

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

On ven., 2015-11-06 at 10:11 -0800, Kees Cook wrote:
> I think GRKERNSEC_KERN_LOCKOUT is kind of on both sides of the
> kernel/userspace defense fence. For now, I think the granularity of
> response for KSPP-ported features will likely just be a full system
> Oops. But I suspect once more of them land, we'll want the finer
> granularity that GRKERNSEC_KERN_LOCKOUT provides.

Yes I was really mentioning GRKERNSEC_BRUTE because it looks similar
to GRKERNSEC_KERN_LOCKOUT but I was more interested by the latter in the
current context. In any case (whether we want fine-grained stuff or not), I
think we definitely need a way to prevent repeated exploit attempts.

Regards,
-- 
Yves-Alexis


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

[kernel-hardening] Re: Kernel Self Protection Project

[Quentin Casasnovas]

On 2015-11-05, Kees Cook <keescook@chromium.org> wrote:
> I'm organizing a community of people to work on the various kernel
> self-protection technologies (most of which are found in PaX and
> Grsecurity). I'm building on the presentation I gave at Kernel Summit
> where I sought to convince the other upstream Linux kernel developers
> that security is more than fixing bugs, and that we need to bring in
> proactive defenses:
> http://lwn.net/Articles/662219/
>

Great initiative!

>
> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
> gcc plugin, which will also get us the gcc plugin infrastructure.
> Other people, please speak up on what you'd like to tackle.
>

Not that it's complex but I already have a branch with the gcc plugin
infrastructure split up if you're interested and you reckon that can save
you some time.

Quentin

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas
<quentin.casasnovas@oracle.com> wrote:
> On 2015-11-05, Kees Cook <keescook@chromium.org> wrote:
>> I'm organizing a community of people to work on the various kernel
>> self-protection technologies (most of which are found in PaX and
>> Grsecurity). I'm building on the presentation I gave at Kernel Summit
>> where I sought to convince the other upstream Linux kernel developers
>> that security is more than fixing bugs, and that we need to bring in
>> proactive defenses:
>> http://lwn.net/Articles/662219/
>>
>
> Great initiative!
>
>>
>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>> gcc plugin, which will also get us the gcc plugin infrastructure.
>> Other people, please speak up on what you'd like to tackle.
>>
>
> Not that it's complex but I already have a branch with the gcc plugin
> infrastructure split up if you're interested and you reckon that can save
> you some time.

Sure, what's the URL?

I actually think that just splitting out features might be a good
first step all around. Most folks aren't very familiar with the
PaX/Grsec patches, and they, in their monolithic nature, can be hard
to understand. Many depend on each other, but some are separable.

I'm also hoping Emese Revfy[1] might be interested in driving
PAX_SIZE_OVERFLOW too, which would be terrific, since she's way more
qualified than me to do it. /me awaits emails. :)

-Kees

[1] https://github.com/ephox-gcc-plugins/size_overflow

-- 
Kees Cook
Chrome OS Security

[kernel-hardening] Re: Kernel Self Protection Project

[Quentin Casasnovas]

On 2015-11-06, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas
><quentin.casasnovas@oracle.com> wrote:
>>>
>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>>> gcc plugin, which will also get us the gcc plugin infrastructure.
>>> Other people, please speak up on what you'd like to tackle.
>>>
>>
>> Not that it's complex but I already have a branch with the gcc plugin
>> infrastructure split up if you're interested and you reckon that can save
>> you some time.
>
> Sure, what's the URL?
> 

I've pushed the three of them onto:

  https://github.com/casasnovas/linux/commits/quentin-spk-gcc-plugin

It lacks Documentation for now, but you can have a look at the branch
quentin-fuzz-gccplugin which adds an instrumentation plugin (converted from
the gcc patch[1] Dmitry Vyukov wrote for syzkaller[2]).

Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
the regular kbuild system way to specify from which source files it is
built, CFLAGS, etc.

  $(HOSTLIBS)-y = foo.so
  foo-objs = foo.c bar.c

And then to have some compilations units be compiled using foo.so, they
just need the following in their CFLAGS:

 -fplugin=$(objtree)/path/to/foo.so


  [1] https://codereview.appspot.com/267910043
  [2] https://github.com/google/syzkaller

All of this is taken from the grsecurity/PaX Team patchset.

>
> I actually think that just splitting out features might be a good
> first step all around. Most folks aren't very familiar with the
> PaX/Grsec patches, and they, in their monolithic nature, can be hard
> to understand. Many depend on each other, but some are separable.
>

Agreed, that should be a required step before people can review.

> I'm also hoping Emese Revfy[1] might be interested in driving
> PAX_SIZE_OVERFLOW too, which would be terrific, since she's way more
> qualified than me to do it. /me awaits emails. :)
>
> -Kees
>
> [1] https://github.com/ephox-gcc-plugins/size_overflow
>

Quentin

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Sat, Nov 7, 2015 at 1:52 AM, Quentin Casasnovas
<quentin.casasnovas@oracle.com> wrote:
> On 2015-11-06, Kees Cook <keescook@chromium.org> wrote:
>> On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas
>><quentin.casasnovas@oracle.com> wrote:
>>>>
>>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>>>> gcc plugin, which will also get us the gcc plugin infrastructure.
>>>> Other people, please speak up on what you'd like to tackle.
>>>>
>>>
>>> Not that it's complex but I already have a branch with the gcc plugin
>>> infrastructure split up if you're interested and you reckon that can save
>>> you some time.
>>
>> Sure, what's the URL?
>>
>
> I've pushed the three of them onto:
>
>   https://github.com/casasnovas/linux/commits/quentin-spk-gcc-plugin

Excellent, thanks for putting that up. I'll take a look.

Given Emese's comments in the other thread, I may actually pass on
this as my first piece to tackle. I may wait to see the constify
plugin go in first.

>
> It lacks Documentation for now, but you can have a look at the branch
> quentin-fuzz-gccplugin which adds an instrumentation plugin (converted from
> the gcc patch[1] Dmitry Vyukov wrote for syzkaller[2]).

syzkaller has been producing some very interesting bugs lately!

>
> Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
> the regular kbuild system way to specify from which source files it is
> built, CFLAGS, etc.
>
>   $(HOSTLIBS)-y = foo.so
>   foo-objs = foo.c bar.c
>
> And then to have some compilations units be compiled using foo.so, they
> just need the following in their CFLAGS:
>
>  -fplugin=$(objtree)/path/to/foo.so
>
>
>   [1] https://codereview.appspot.com/267910043
>   [2] https://github.com/google/syzkaller
>
> All of this is taken from the grsecurity/PaX Team patchset.
>
>>
>> I actually think that just splitting out features might be a good
>> first step all around. Most folks aren't very familiar with the
>> PaX/Grsec patches, and they, in their monolithic nature, can be hard
>> to understand. Many depend on each other, but some are separable.
>>
>
> Agreed, that should be a required step before people can review.

Yeah. Does anyone want to also extract PAX_USERCOPY or
GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
yet.

-Kees

>
>> I'm also hoping Emese Revfy[1] might be interested in driving
>> PAX_SIZE_OVERFLOW too, which would be terrific, since she's way more
>> qualified than me to do it. /me awaits emails. :)
>>
>> -Kees
>>
>> [1] https://github.com/ephox-gcc-plugins/size_overflow
>>
>
> Quentin
>



-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Quentin Casasnovas]

On Sat, Nov 07, 2015 at 10:50:04PM -0800, Kees Cook wrote:
> On Sat, Nov 7, 2015 at 1:52 AM, Quentin Casasnovas
> <quentin.casasnovas@oracle.com> wrote:
> >>
> >> I actually think that just splitting out features might be a good
> >> first step all around. Most folks aren't very familiar with the
> >> PaX/Grsec patches, and they, in their monolithic nature, can be hard
> >> to understand. Many depend on each other, but some are separable.
> >>
> >
> > Agreed, that should be a required step before people can review.
> 
> Yeah. Does anyone want to also extract PAX_USERCOPY or
> GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
> yet.
> 

I could have a look at splitting GRKERNSEC_KSTACKOVERFLOW on my free time
if no-one beats me to it.

Quentin

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Sun, Nov 8, 2015 at 2:45 AM, Quentin Casasnovas
<quentin.casasnovas@oracle.com> wrote:
> On Sat, Nov 07, 2015 at 10:50:04PM -0800, Kees Cook wrote:
>> On Sat, Nov 7, 2015 at 1:52 AM, Quentin Casasnovas
>> <quentin.casasnovas@oracle.com> wrote:
>> >>
>> >> I actually think that just splitting out features might be a good
>> >> first step all around. Most folks aren't very familiar with the
>> >> PaX/Grsec patches, and they, in their monolithic nature, can be hard
>> >> to understand. Many depend on each other, but some are separable.
>> >>
>> >
>> > Agreed, that should be a required step before people can review.
>>
>> Yeah. Does anyone want to also extract PAX_USERCOPY or
>> GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
>> yet.
>>
>
> I could have a look at splitting GRKERNSEC_KSTACKOVERFLOW on my free time
> if no-one beats me to it.

Sounds great! Please keep us posted. :)

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Valdis.Kletnieks]

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

On Sat, 07 Nov 2015 22:50:04 -0800, Kees Cook said:

> Yeah. Does anyone want to also extract PAX_USERCOPY or
> GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
> yet.

I'll commit to at least looking at PAX_USERCOPY.  Looks reasonably
stand-alone.

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [kernel-hardening] Re: Kernel Self Protection Project

[David Windsor]

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

The problem is cherrypicking these things from the original patchsets.  I'm
doing that now for PAX_REFCOUNT, and it's proving more difficult than I
originally expected.

On Mon, Nov 9, 2015 at 4:44 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Sat, 07 Nov 2015 22:50:04 -0800, Kees Cook said:
>
> > Yeah. Does anyone want to also extract PAX_USERCOPY or
> > GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
> > yet.
>
> I'll commit to at least looking at PAX_USERCOPY.  Looks reasonably
> stand-alone.
>

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

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Mon, Nov 9, 2015 at 1:55 PM, David Windsor <dave@0x4141.net> wrote:
>
> On Mon, Nov 9, 2015 at 4:44 PM, <Valdis.Kletnieks@vt.edu> wrote:
>>
>> On Sat, 07 Nov 2015 22:50:04 -0800, Kees Cook said:
>>
>> > Yeah. Does anyone want to also extract PAX_USERCOPY or
>> > GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
>> > yet.
>>
>> I'll commit to at least looking at PAX_USERCOPY.  Looks reasonably
>> stand-alone.
>
> The problem is cherrypicking these things from the original patchsets.  I'm
> doing that now for PAX_REFCOUNT, and it's proving more difficult than I
> originally expected.

Yes! Things are rather intertwined. :)

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Quentin Casasnovas]

On Mon, Nov 09, 2015 at 04:55:34PM -0500, David Windsor wrote:
> The problem is cherrypicking these things from the original patchsets.  I'm
> doing that now for PAX_REFCOUNT, and it's proving more difficult than I
> originally expected.

If you're not already using it, you might find easier to work from the
github Mickaël Salaün has set up, something along those lines:

  cd linux-2.6
  git remote add linux-grsecurity https://github.com/linux-scraping/linux-grsecurity.git
  git fetch linux-grsecurity
  git checkout -b grsecurity-pax-refcount-split v4.2.5
  git checkout -p linux-grsecurity -- $(git grep -l PAX_REFCOUNT linux-grsecurity/grsec-4.2)

Which will drop you into a sub-shell where you can pick relevant hunks.
Then you can repeat the last line replacing PAX_REFCOUNT with any new
symbols that you've picked on the way.
  
Quentin

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Mon, Nov 9, 2015 at 1:44 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 07 Nov 2015 22:50:04 -0800, Kees Cook said:
>
>> Yeah. Does anyone want to also extract PAX_USERCOPY or
>> GRKERNSEC_KSTACKOVERFLOW ? No one has mentioned an interest in those
>> yet.
>
> I'll commit to at least looking at PAX_USERCOPY.  Looks reasonably
> stand-alone.

Great! Please keep us posted.

-Kees

-- 
Kees Cook
Chrome OS Security

[kernel-hardening] Re: Kernel Self Protection Project

[Rasmus Villemoes]

On Sat, Nov 07 2015, Quentin Casasnovas <quentin.casasnovas@oracle.com> wrote:

> On 2015-11-06, Kees Cook <keescook@chromium.org> wrote:
>> On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas
>><quentin.casasnovas@oracle.com> wrote:
>>>>
>>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
>>>> gcc plugin, which will also get us the gcc plugin infrastructure.
>>>> Other people, please speak up on what you'd like to tackle.
>>>>
>>>
>>> Not that it's complex but I already have a branch with the gcc plugin
>>> infrastructure split up if you're interested and you reckon that can save
>>> you some time.
>>
>> Sure, what's the URL?
>> 
>
> I've pushed the three of them onto:
>
>   https://github.com/casasnovas/linux/commits/quentin-spk-gcc-plugin
>
> It lacks Documentation for now, but you can have a look at the branch
> quentin-fuzz-gccplugin which adds an instrumentation plugin (converted from
> the gcc patch[1] Dmitry Vyukov wrote for syzkaller[2]).
>
> Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
> the regular kbuild system way to specify from which source files it is
> built, CFLAGS, etc.
>
>   $(HOSTLIBS)-y = foo.so
>   foo-objs = foo.c bar.c
>
> And then to have some compilations units be compiled using foo.so, they
> just need the following in their CFLAGS:
>
>  -fplugin=$(objtree)/path/to/foo.so

Nice, thanks. But wouldn't it be even more userfriendly to have these
things driven by Kconfig? So let (use of) each plugin depend on a
CONFIG_GCCPLUGIN_XYZ variable, which will automatically turn itself off
(with a warning) if that plugin can't be used for whatever
reason. That'll also give a natural place to say a little about the
plugin (though I also think Documentation/gccplugins/* should be
created). We could hide these behind CONFIG_USE_GCCPLUGINS to make it
easy for people to turn off.

I suppose some plugins are really all-or-nothing (e.g. when randomizing
structs, the various TUs better agree on what shuffling has been done),
so for them it doesn't make sense to apply to individual C files. Is
something done to ensure that, and if not, can it be done with some
linker magic? (Something like putting a hash of the used random seed in
each object file and make the linker complain if there are distinct
definitions of that magic symbol.)

Rasmus

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Quentin Casasnovas]

On Mon, Nov 09, 2015 at 11:02:47AM +0100, Rasmus Villemoes wrote:
> On Sat, Nov 07 2015, Quentin Casasnovas <quentin.casasnovas@oracle.com> wrote:
> 
> > On 2015-11-06, Kees Cook <keescook@chromium.org> wrote:
> >> On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas
> >><quentin.casasnovas@oracle.com> wrote:
> >>>>
> >>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
> >>>> gcc plugin, which will also get us the gcc plugin infrastructure.
> >>>> Other people, please speak up on what you'd like to tackle.
> >>>>
> >>>
> >>> Not that it's complex but I already have a branch with the gcc plugin
> >>> infrastructure split up if you're interested and you reckon that can save
> >>> you some time.
> >>
> >> Sure, what's the URL?
> >> 
> >
> > I've pushed the three of them onto:
> >
> >   https://github.com/casasnovas/linux/commits/quentin-spk-gcc-plugin
> >
> > It lacks Documentation for now, but you can have a look at the branch
> > quentin-fuzz-gccplugin which adds an instrumentation plugin (converted from
> > the gcc patch[1] Dmitry Vyukov wrote for syzkaller[2]).
> >
> > Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
> > the regular kbuild system way to specify from which source files it is
> > built, CFLAGS, etc.
> >
> >   $(HOSTLIBS)-y = foo.so
> >   foo-objs = foo.c bar.c
> >
> > And then to have some compilations units be compiled using foo.so, they
> > just need the following in their CFLAGS:
> >
> >  -fplugin=$(objtree)/path/to/foo.so
> 
> Nice, thanks. But wouldn't it be even more userfriendly to have these
> things driven by Kconfig? So let (use of) each plugin depend on a
> CONFIG_GCCPLUGIN_XYZ variable, which will automatically turn itself off
> (with a warning) if that plugin can't be used for whatever
> reason. That'll also give a natural place to say a little about the
> plugin (though I also think Documentation/gccplugins/* should be
> created). We could hide these behind CONFIG_USE_GCCPLUGINS to make it
> easy for people to turn off.
> 

Ah agreed, this was just so people could get started quickly.  The way to
do this is to include your plugin flags inside the Makefile variable
GCC_PLUGIN_CFLAGS, which is exported and stuffed to the KBUILD_CFLAGS.

So if you have plugin foo.so that you want to be used for all of the
compilation units (and which depends on CONFIG_FOO), then it should be as
simple as doing this in the top-level Makefile:

ifeq ($(CONFIG_FOO),y)
 GCC_PLUGIN_CFLAGS += -fplugin=$(objtree)/path/to/foo.so
endif

The grsecurity/PaX patchset already deals with gcc version and
GCC_PLUGIN_CFLAGS will only be exported if your gcc version supports
plugins, otherwise it'll dump a warning and carry on compiling your kernel.

Hope that clarifies things :)

> 
> I suppose some plugins are really all-or-nothing (e.g. when randomizing
> structs, the various TUs better agree on what shuffling has been done),
> so for them it doesn't make sense to apply to individual C files.

It was probably a bad example on my side, you'll probably indeed compile
your plugins for the whole kernel as opposed to per-file (it's just that
I'm using the instrumentation plugin from syzkaller on just a few files at
the moment.. so it's the first example that came to my mind).

> Is something done to ensure that, and if not, can it be done with some
> linker magic? (Something like putting a hash of the used random seed in
> each object file and make the linker complain if there are distinct
> definitions of that magic symbol.)
>

I believe/hope the kernel would have trouble booting if there was such a
disreptancy here, though this check sounds like a sensible thing to add to
be notified early of such unexpected cases!

Quentin

[kernel-hardening] Re: Kernel Self Protection Project

[Rasmus Villemoes]

On Mon, Nov 09 2015, Quentin Casasnovas <quentin.casasnovas@oracle.com> wrote:

>> >
>> > Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
>> > the regular kbuild system way to specify from which source files it is
>> > built, CFLAGS, etc.
>> >
>> >   $(HOSTLIBS)-y = foo.so
>> >   foo-objs = foo.c bar.c
>> >
>> > And then to have some compilations units be compiled using foo.so, they
>> > just need the following in their CFLAGS:
>> >
>> >  -fplugin=$(objtree)/path/to/foo.so
>> 
>> Nice, thanks. But wouldn't it be even more userfriendly to have these
>> things driven by Kconfig? So let (use of) each plugin depend on a
>> CONFIG_GCCPLUGIN_XYZ variable, which will automatically turn itself off
>> (with a warning) if that plugin can't be used for whatever
>> reason. That'll also give a natural place to say a little about the
>> plugin (though I also think Documentation/gccplugins/* should be
>> created). We could hide these behind CONFIG_USE_GCCPLUGINS to make it
>> easy for people to turn off.
>> 
>
> Ah agreed, this was just so people could get started quickly.  The way to
> do this is to include your plugin flags inside the Makefile variable
> GCC_PLUGIN_CFLAGS, which is exported and stuffed to the KBUILD_CFLAGS.
>
> So if you have plugin foo.so that you want to be used for all of the
> compilation units (and which depends on CONFIG_FOO), then it should be as
> simple as doing this in the top-level Makefile:
>
> ifeq ($(CONFIG_FOO),y)
>  GCC_PLUGIN_CFLAGS += -fplugin=$(objtree)/path/to/foo.so
> endif
>
> The grsecurity/PaX patchset already deals with gcc version and
> GCC_PLUGIN_CFLAGS will only be exported if your gcc version supports
> plugins, otherwise it'll dump a warning and carry on compiling your kernel.
>
> Hope that clarifies things :)

It does.

It would be nice if the plugin infrastructure was as self-contained as
possible, and to get whatever is decided acked by the kbuild maintainers
and Linus well before 4.5.

Is it possible to make a scheme where existing files are touched as
little as possible? E.g. putting all the makefile magic in
e.g. scripts/Makefile.plugins, the Kconfig symbols in
lib/Kconfig.plugins, and the source of the plugins are in lib/plugins/
(at first just in that single directory, which will also make sharing
code between the plugins slightly easier).

Rasmus

Re: [kernel-hardening] Re: Kernel Self Protection Project

[Kees Cook]

On Mon, Nov 9, 2015 at 11:24 AM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On Mon, Nov 09 2015, Quentin Casasnovas <quentin.casasnovas@oracle.com> wrote:
>
>>> >
>>> > Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use
>>> > the regular kbuild system way to specify from which source files it is
>>> > built, CFLAGS, etc.
>>> >
>>> >   $(HOSTLIBS)-y = foo.so
>>> >   foo-objs = foo.c bar.c
>>> >
>>> > And then to have some compilations units be compiled using foo.so, they
>>> > just need the following in their CFLAGS:
>>> >
>>> >  -fplugin=$(objtree)/path/to/foo.so
>>>
>>> Nice, thanks. But wouldn't it be even more userfriendly to have these
>>> things driven by Kconfig? So let (use of) each plugin depend on a
>>> CONFIG_GCCPLUGIN_XYZ variable, which will automatically turn itself off
>>> (with a warning) if that plugin can't be used for whatever
>>> reason. That'll also give a natural place to say a little about the
>>> plugin (though I also think Documentation/gccplugins/* should be
>>> created). We could hide these behind CONFIG_USE_GCCPLUGINS to make it
>>> easy for people to turn off.
>>>
>>
>> Ah agreed, this was just so people could get started quickly.  The way to
>> do this is to include your plugin flags inside the Makefile variable
>> GCC_PLUGIN_CFLAGS, which is exported and stuffed to the KBUILD_CFLAGS.
>>
>> So if you have plugin foo.so that you want to be used for all of the
>> compilation units (and which depends on CONFIG_FOO), then it should be as
>> simple as doing this in the top-level Makefile:
>>
>> ifeq ($(CONFIG_FOO),y)
>>  GCC_PLUGIN_CFLAGS += -fplugin=$(objtree)/path/to/foo.so
>> endif
>>
>> The grsecurity/PaX patchset already deals with gcc version and
>> GCC_PLUGIN_CFLAGS will only be exported if your gcc version supports
>> plugins, otherwise it'll dump a warning and carry on compiling your kernel.
>>
>> Hope that clarifies things :)
>
> It does.
>
> It would be nice if the plugin infrastructure was as self-contained as
> possible, and to get whatever is decided acked by the kbuild maintainers
> and Linus well before 4.5.

Emese mentioned that it just disables itself when the gcc version is
too early. I do a similar thing for handling gcc 4.9+'s addition of
-fstack-protector-strong.

> Is it possible to make a scheme where existing files are touched as
> little as possible? E.g. putting all the makefile magic in
> e.g. scripts/Makefile.plugins, the Kconfig symbols in
> lib/Kconfig.plugins, and the source of the plugins are in lib/plugins/
> (at first just in that single directory, which will also make sharing
> code between the plugins slightly easier).

I don't see why not. I'm sure Emese will get all kinds of feedback
after the initify plugin patches start getting sent. :)

One thing (that doesn't need fixing as a prerequisite) that I'd love
to see out of Kconfig is a more sensible separation between config
regeneration and actual kernel build stages. Right now, for example, I
couldn't find a way to detect the lack of -fstack-protector-strong
without also breaking the config regeneration stage. I can only emit a
warning and then have the build fail due to not understanding
-fstack-protector-strong. (I do not want it to just silently disable,
because that means you can get differing protections from the same
.config depending on your compiler: if you asked for
CC_STACKPROTECTOR_STRONG, the kernel must build with it.) I imagine
we'll face a similar issue with the plugin infrastructure.

-Kees

-- 
Kees Cook
Chrome OS Security

[kernel-hardening] Binary blobs

[HacKurx]

Hi all,

First, thank you all for your work.
I allow myself to discuss an issue with a quote:

The binary blobs are a potential for undetectable or irreparable 
security flaws (Andrews Jeremy "Interview: Theo de Raadt", KernelTrap).

What is your point of view? Linux-libre kernel is the only reliable 
basis?

Best regards,

Re: [kernel-hardening] Binary blobs

[Valdis.Kletnieks]

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

On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
> The binary blobs are a potential for undetectable or irreparable
> security flaws (Andrews Jeremy "Interview: Theo de Raadt", KernelTrap).
>
> What is your point of view? Linux-libre kernel is the only reliable
> basis?

Closed source is by definition not easily examined for security issues (though
once you get to monsters like LibreOffice or Firefox, even open source code
is difficult to audit).

The problem is that at the current time, not all software is easily opened. For
example, the single biggest reason (among several) that NVidia has a binary
blob driver is that (simplifying *drastically* here) when SGI's graphics
division imploded, NVidia got all the engineers - but Microsoft snarfed up a
bunch of patents connected to OpenGL.  So NVidia had no realistic choice but to
license the intellectual property from Microsoft.

So out in the real world, you have to look at your threat model, and decide
how paranoid you are.  (Personally, I'd be more worried about the open-sourced
Firefox code than I would the NVidia binary blob.  The former has got a *huge*
attack surface compared to the latter....)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [kernel-hardening] Binary blobs

[Kees Cook]

On Mon, Nov 9, 2015 at 2:20 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
>> The binary blobs are a potential for undetectable or irreparable
>> security flaws (Andrews Jeremy "Interview: Theo de Raadt", KernelTrap).
>>
>> What is your point of view? Linux-libre kernel is the only reliable
>> basis?
>
> Closed source is by definition not easily examined for security issues (though
> once you get to monsters like LibreOffice or Firefox, even open source code
> is difficult to audit).
>
> The problem is that at the current time, not all software is easily opened. For
> example, the single biggest reason (among several) that NVidia has a binary
> blob driver is that (simplifying *drastically* here) when SGI's graphics
> division imploded, NVidia got all the engineers - but Microsoft snarfed up a
> bunch of patents connected to OpenGL.  So NVidia had no realistic choice but to
> license the intellectual property from Microsoft.
>
> So out in the real world, you have to look at your threat model, and decide
> how paranoid you are.  (Personally, I'd be more worried about the open-sourced
> Firefox code than I would the NVidia binary blob.  The former has got a *huge*
> attack surface compared to the latter....)

I think the first step is making sure you know _what_ blobs you're
loading, and to have a known list of them. (There are efforts started
with signed firmware[1] validation or the loadpin[2] LSM -- though
neither yet deal with userspace loaded blobs like graphics drivers,
SSD firmware, etc). This would block having blobs be manipulated
maliciously before they're loaded. After that mechanism is in place,
then it'd be useful to reverse engineer them to find security flaws.

-Kees

[1] http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002238.html
[2] http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=lsm/loadpin

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening] Binary blobs

[HacKurx]

Le 2015-11-09 23:20, Valdis.Kletnieks@vt.edu a écrit :
> On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
>> The binary blobs are a potential for undetectable or irreparable
>> security flaws (Andrews Jeremy "Interview: Theo de Raadt", 
>> KernelTrap).
>> 
>> What is your point of view? Linux-libre kernel is the only reliable
>> basis?
> 
> Closed source is by definition not easily examined for security issues 
> (though
> once you get to monsters like LibreOffice or Firefox, even open source 
> code
> is difficult to audit).
> 
> The problem is that at the current time, not all software is easily 
> opened. For
> example, the single biggest reason (among several) that NVidia has a 
> binary
> blob driver is that (simplifying *drastically* here) when SGI's 
> graphics
> division imploded, NVidia got all the engineers - but Microsoft snarfed 
> up a
> bunch of patents connected to OpenGL.  So NVidia had no realistic 
> choice but to
> license the intellectual property from Microsoft.
> 
> So out in the real world, you have to look at your threat model, and 
> decide
> how paranoid you are.  (Personally, I'd be more worried about the 
> open-sourced
> Firefox code than I would the NVidia binary blob.  The former has got a 
> *huge*
> attack surface compared to the latter....)

Yes indeed. But for your information you can use Firefox with MPROTECT 
and all hardened options for GCC.
http://hardenedgentoo.blogspot.fr/2012/02/firefox-1001-mprotect-strikes-again.html

Disable in firefox: methodjit, tracejit & ion. The performance remains 
very good :)

Le 2015-11-10 00:33, Kees Cook a écrit :
> On Mon, Nov 9, 2015 at 2:20 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>> On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
>>> The binary blobs are a potential for undetectable or irreparable
>>> security flaws (Andrews Jeremy "Interview: Theo de Raadt", 
>>> KernelTrap).
>>> 
>>> What is your point of view? Linux-libre kernel is the only reliable
>>> basis?
>> 
>> Closed source is by definition not easily examined for security issues 
>> (though
>> once you get to monsters like LibreOffice or Firefox, even open source 
>> code
>> is difficult to audit).
>> 
>> The problem is that at the current time, not all software is easily 
>> opened. For
>> example, the single biggest reason (among several) that NVidia has a 
>> binary
>> blob driver is that (simplifying *drastically* here) when SGI's 
>> graphics
>> division imploded, NVidia got all the engineers - but Microsoft 
>> snarfed up a
>> bunch of patents connected to OpenGL.  So NVidia had no realistic 
>> choice but to
>> license the intellectual property from Microsoft.
>> 
>> So out in the real world, you have to look at your threat model, and 
>> decide
>> how paranoid you are.  (Personally, I'd be more worried about the 
>> open-sourced
>> Firefox code than I would the NVidia binary blob.  The former has got 
>> a *huge*
>> attack surface compared to the latter....)
> 
> I think the first step is making sure you know _what_ blobs you're
> loading, and to have a known list of them. (There are efforts started
> with signed firmware[1] validation or the loadpin[2] LSM -- though
> neither yet deal with userspace loaded blobs like graphics drivers,
> SSD firmware, etc). This would block having blobs be manipulated
> maliciously before they're loaded. After that mechanism is in place,
> then it'd be useful to reverse engineer them to find security flaws.
> 
> -Kees
> 
> [1]
> http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002238.html
> [2]
> http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=lsm/loadpin

Okay, thanks for the clarifications

-- 
Best regards,

Re: [kernel-hardening] Binary blobs

[Daniel Micay]

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

> all hardened options for GCC.

Well, you probably can't get away with -fsanitize=undefined
-fsanitize-undefined-trap-on-error yet (object-size and
signed-integer-overflow checks specifically). I know what you mean
though :).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Binary blobs

[HacKurx]

Le 2015-11-13 09:07, Daniel Micay a écrit :
>> all hardened options for GCC.
> 
> Well, you probably can't get away with -fsanitize=undefined
> -fsanitize-undefined-trap-on-error yet (object-size and
> signed-integer-overflow checks specifically). I know what you mean
> though :).

Yes you are right, it is easy to have a warning but not a correction.

But with mprotect and:
CFLAGS="-fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security"
CPPFLAGS="-D_FORTIFY_SOURCE=2"
LDFLAGS="-Wl,-z,relro"

It's already better than the official release :D

-- 
Best regards,

Re: [kernel-hardening] Kernel Self Protection Project

[Mickaël Salaün]

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

Excellent initiative!

FYI, you can find the grsecurity patches automatically integrated in a consistent Git repository: https://github.com/linux-scraping/linux-grsecurity . I took all patches I could find (with their signatures and changelogs!), starting from the beginning of the Linux Git history (2005: v2.6.14.2), and applying them following branches and merges. The result is quite interesting and help to dive into the Linux/grsecurity internals (with log, blame and bisect). Moreover, it show the work of Brad Spengler backporting fixes.
I did the same with PaX but it needs some more work before going public.

Regards,
 Mickaël


On 11/05/15 21:59, Kees Cook wrote:
> I'm organizing a community of people to work on the various kernel
> self-protection technologies (most of which are found in PaX and
> Grsecurity). I'm building on the presentation I gave at Kernel Summit
> where I sought to convince the other upstream Linux kernel developers
> that security is more than fixing bugs, and that we need to bring in
> proactive defenses:
> http://lwn.net/Articles/662219/
> 
> This is especially highlighted by the Washington Post article today:
> http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/
> 
> Between the companies that recognize the critical nature of this work,
> and with Linux Foundation's Core Infrastructure Initiative happy to
> start funding specific work in this area, I think we can really make a
> dent.
> 
> Let's start the work. I've built some wiki pages around my slides,
> where we can take notes, list examples, and coordinate:
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
> 
> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW
> gcc plugin, which will also get us the gcc plugin infrastructure.
> Other people, please speak up on what you'd like to tackle.
> 
> I recommend PAX_REFCOUNT, PAX_USERCOPY, and GRKERNSEC_KSTACKOVERFLOW
> for some non-plugin stuff to look at.
> 
> Once we've got plugins, then we should look at PAX_MEMORY_STACKLEAK
> and PAX_CONSTIFY_PLUGIN.
> 
> If you're feeling like disrupting people who depend on debugging, do
> GRKERNSEC_HIDESYM.
> 
> If you're feeling especially bold, start on PAX_KERNEXEC and follow it
> up with PAX_MEMORY_UDEREF.
> 
> Of course, there's plenty of other things, and tons I haven't listed
> in the wiki -- please add them and bring them up for discussion here.
> 
> -Kees
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [kernel-hardening] Kernel Self Protection Project

[Kees Cook]

On Fri, Nov 6, 2015 at 1:27 PM, Mickaël Salaün <mic@digikod.net> wrote:
> Excellent initiative!
>
> FYI, you can find the grsecurity patches automatically integrated in a consistent Git repository: https://github.com/linux-scraping/linux-grsecurity . I took all patches I could find (with their signatures and changelogs!), starting from the beginning of the Linux Git history (2005: v2.6.14.2), and applying them following branches and merges. The result is quite interesting and help to dive into the Linux/grsecurity internals (with log, blame and bisect). Moreover, it show the work of Brad Spengler backporting fixes.
> I did the same with PaX but it needs some more work before going public.

Thanks for the pointer! This could be a nice resource for people who
want to take a closer look at the history.

Related to resources, I also think it'd be great to start a collection
of relevant academic papers too, and get them linked off the wiki.
Does anyone have a few they think are especially notable?

-Kees

-- 
Kees Cook
Chrome OS Security