[kernel-hardening] Project convention on configuration options

[kernel-hardening] Project convention on configuration options

[Schaufler, Casey]

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


I'm starting to look at PAX_USERCOPY and immediately hit
the question of what to do about configuration option name.
I assume that retaining PAX_USERCOPY is not the right thing
to do, but what should be used instead? HARD_USERCOPY?

Thanks.


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

Re: [kernel-hardening] Project convention on configuration options

[Kees Cook]

On Fri, Dec 11, 2015 at 9:57 AM, Schaufler, Casey
<casey.schaufler@intel.com> wrote:
> I’m starting to look at PAX_USERCOPY and immediately hit
> the question of what to do about configuration option name.
> I assume that retaining PAX_USERCOPY is not the right thing
> to do, but what should be used instead? HARD_USERCOPY?

I think there will be plenty of bike-shedding, so pick whatever you
like for now. :)

There is already the (disabled due to gcc bugs)
DEBUG_STRICT_USER_COPY_CHECKS (which should lose the "DEBUG" name
too). IIRC, it works by tracking memory regions? Maybe TRACK_USERCOPY?
I'm sure it'll get renamed, so no big deal. In fact, you could just
leave it as PAX_USERCOPY too for the initial extraction.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Project convention on configuration options

[Daniel Micay]

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

> I think there will be plenty of bike-shedding, so pick whatever you
> like for now. :)
> 
> There is already the (disabled due to gcc bugs)
> DEBUG_STRICT_USER_COPY_CHECKS (which should lose the "DEBUG" name
> too). IIRC, it works by tracking memory regions? Maybe TRACK_USERCOPY?
> I'm sure it'll get renamed, so no big deal. In fact, you could just
> leave it as PAX_USERCOPY too for the initial extraction.

The main component is dynamically querying the slab allocator for the
allocation sizes. It also has checking for stack frames and global data.
There are also some tweaks related to __builtin_object_size.

It would make sense to land it in pieces, perhaps starting with the slab
allocator stuff (which is the bulk of the changes since some slabs need
to be marked and it seems like it would be the least controversial part
of the feature).

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

Re: [kernel-hardening] Project convention on configuration options

[HacKurx]

First, respect the work of others...
https://twitter.com/ioerror/status/636677916365996032

So I hope you are not here for nothing...
Sorry for such a comment here but I don't like attitude of your enterprise.

2015-12-11 18:57 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
>
>
> I’m starting to look at PAX_USERCOPY and immediately hit
> the question of what to do about configuration option name.
> I assume that retaining PAX_USERCOPY is not the right thing
> to do, but what should be used instead? HARD_USERCOPY?
>
> Thanks.
>
>

-- 
Best regards,

Re: [kernel-hardening] Project convention on configuration options

[Kees Cook]

On Fri, Dec 11, 2015 at 12:24 PM, HacKurx <hackurx@gmail.com> wrote:
> First, respect the work of others...
> https://twitter.com/ioerror/status/636677916365996032

What? You might want to read through the archives. We, of course, give
credit. Just look at my attempts to port __read_only. PaX and
Grsecurity are credited. Emese is actively involved in getting CII
funding for upstream porting work, and PaX Team will comment now and
then too. I see no lack of respect.

> So I hope you are not here for nothing...
> Sorry for such a comment here but I don't like attitude of your enterprise.

I'm sorry you feel that way. What led you to thinking we had a bad
attitude about our efforts to bring PaX and Grsecurity features into
mainline?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

RE: [kernel-hardening] Project convention on configuration options

[Schaufler, Casey]

> -----Original Message-----
> From: HacKurx [mailto:hackurx@gmail.com]
> Sent: Friday, December 11, 2015 12:25 PM
> To: kernel-hardening@lists.openwall.com
> Subject: Re: [kernel-hardening] Project convention on configuration options
> 
> First, respect the work of others...
> https://twitter.com/ioerror/status/636677916365996032
> 
> So I hope you are not here for nothing...
> Sorry for such a comment here but I don't like attitude of your enterprise.

Noted.

So, on the topic at hand, what would you suggest? I see real
value in retaining as much of what's been proposed before as
possible.

> 
> 2015-12-11 18:57 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
> >
> >
> > I’m starting to look at PAX_USERCOPY and immediately hit
> > the question of what to do about configuration option name.
> > I assume that retaining PAX_USERCOPY is not the right thing
> > to do, but what should be used instead? HARD_USERCOPY?
> >
> > Thanks.
> >
> >
> 
> --
> Best regards,

Re: [kernel-hardening] Project convention on configuration options

[HacKurx]

2015-12-11 22:09 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
> Noted.
>
> So, on the topic at hand, what would you suggest? I see real
> value in retaining as much of what's been proposed before as
> possible.

I don't understand why Intel and the Core Infrastructure Initiative
does not sponsor grsecurity.
Grsecurity is just as important as OpenSSL.
They need help to continue!


-- 
Best regards,

Re: [kernel-hardening] Project convention on configuration options

[Kees Cook]

On Fri, Dec 11, 2015 at 1:48 PM, HacKurx <hackurx@gmail.com> wrote:
> 2015-12-11 22:09 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
>> Noted.
>>
>> So, on the topic at hand, what would you suggest? I see real
>> value in retaining as much of what's been proposed before as
>> possible.
>
> I don't understand why Intel and the Core Infrastructure Initiative
> does not sponsor grsecurity.
> Grsecurity is just as important as OpenSSL.
> They need help to continue!

I can't speak for Intel or CII directly, but I'd point out that CII
*is* involved in a funding proposal from Emese, who is the author of
several of the PaX GCC plugins. If you'd like to help with some part
of bringing PaX and Grsecurity features to upstream, please discuss
what you'd like to do here and then bring another proposal to CII for
consideration.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Project convention on configuration options

[HacKurx]

2015-12-11 22:57 GMT+01:00 Kees Cook <keescook@chromium.org>:
> I can't speak for Intel or CII directly, but I'd point out that CII
> *is* involved in a funding proposal from Emese, who is the author of
> several of the PaX GCC plugins. If you'd like to help with some part
> of bringing PaX and Grsecurity features to upstream, please discuss
> what you'd like to do here and then bring another proposal to CII for
> consideration.

That's a good point for Emese. Your work to bring PaX and Grsecurity
features into mainline is also remarkable, thanks.

I stop to bother you and I really hope I haven't offended anyone.

-- 
Best regards,

Re: [kernel-hardening] Project convention on configuration options

[Valdis.Kletnieks]

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

On Fri, 11 Dec 2015 22:48:34 +0100, HacKurx said:

> I don't understand why Intel and the Core Infrastructure Initiative
> does not sponsor grsecurity.
> Grsecurity is just as important as OpenSSL.
> They need help to continue!

The problem is that there's a *lot* of stuff that's just as security-relevant
as OpenSSL, but which hasn't gotten the support it should - things like
NTP (which Eric S Raymond has been cleaning in his spare time), GnuPG, and
probably a raft of other infrastructure.

But it's not clear that it's Intel's problem to support all of it by
itself, and the CII can only do sponsorship to the level that they themselves
have funding...

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

Re: [kernel-hardening] Project convention on configuration options

[HacKurx]

2015-12-11 23:59 GMT+01:00  <Valdis.Kletnieks@vt.edu>:
> But it's not clear that it's Intel's problem to support all of it by
> itself, and the CII can only do sponsorship to the level that they themselves
> have funding...

But so far they know sell (Intel IoT Gateway, Intel MPX, Wind River and more)

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/iot-security-profiles-white-paper.pdf
http://www.intel.com/content/dam/www/public/us/en/documents/guides/wind-river-idp-xt2-programmers-guide.pdf
https://communities.intel.com/community/itpeernetwork/blog/2015/03/16/intel-gateway-solution-is-at-the-center-of-internet-of-things-deployments
https://software.intel.com/sites/default/files/IoT%20Gateway%20IDP%20XT%20GSG.pdf
http://www.intel.com/content/dam/www/public/us/en/documents/research/2014-vol18-iss-4-intel-technology-journal.pdf

-- 
Best regards,

Re: [kernel-hardening] Project convention on configuration options

[Kees Cook]

On Sat, Dec 12, 2015 at 1:17 AM, HacKurx <hackurx@gmail.com> wrote:
> 2015-12-11 23:59 GMT+01:00  <Valdis.Kletnieks@vt.edu>:
>> But it's not clear that it's Intel's problem to support all of it by
>> itself, and the CII can only do sponsorship to the level that they themselves
>> have funding...
>
> But so far they know sell (Intel IoT Gateway, Intel MPX, Wind River and more)
>
> http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/iot-security-profiles-white-paper.pdf
> http://www.intel.com/content/dam/www/public/us/en/documents/guides/wind-river-idp-xt2-programmers-guide.pdf
> https://communities.intel.com/community/itpeernetwork/blog/2015/03/16/intel-gateway-solution-is-at-the-center-of-internet-of-things-deployments
> https://software.intel.com/sites/default/files/IoT%20Gateway%20IDP%20XT%20GSG.pdf
> http://www.intel.com/content/dam/www/public/us/en/documents/research/2014-vol18-iss-4-intel-technology-journal.pdf

Intel's use of grsecurity in their products isn't something we can
meaningfully address on this mailing list.

As outlined on the wiki, and in my other posts, our focus here is on
bringing modern kernel self-protection technologies to upstream where
everyone can benefit from them.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security