Re: [kernel-hardening]

Re: [kernel-hardening]

[west suhanic]

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

Hello All:

I am a hardened gentoo user. How can we get the grsecurity code into the
kernel?

regards,

West Suhanic

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

Re: [kernel-hardening]

[Valdis.Kletnieks]

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

On Fri, 13 Nov 2015 10:43:23 -0500, west suhanic said:
> I am a hardened gentoo user. How can we get the grsecurity code into the
> kernel?

How do you eat an elephant?  One bite at a time. :)

Seriously - some of the grsecurity code will never get into the kernel, because
there's just too wide a philosophy gap.  The rest will have to go into the
kernel the same way any other very large thing does - one set of patches per
stand-alone feature.

That does mean we'll need to tease out each piece separately, and get it
into a format that has a good shot at getting into Linus's tree.

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

Re: [kernel-hardening]

[David Windsor]

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

On Fri, Nov 13, 2015 at 5:23 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Fri, 13 Nov 2015 10:43:23 -0500, west suhanic said:
> > I am a hardened gentoo user. How can we get the grsecurity code into the
> > kernel?
>
> <snip>
>
> That does mean we'll need to tease out each piece separately, and get it
> into a format that has a good shot at getting into Linus's tree.
>

This effort is currently taking place in another thread on
kernel-hardening:
http://www.openwall.com/lists/kernel-hardening/2015/11/05/1.

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

Re: [kernel-hardening]

[Richard Weinberger]

On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
> Hello All:
>
> I am a hardened gentoo user. How can we get the grsecurity code into the
> kernel?

As soon all downsides and drawbacks are identified/resolved.
Which basically means that we have to redo a lot (it not all).

-- 
Thanks,
//richard

Re: [kernel-hardening]

[Daniel Micay]

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

On 15/11/15 03:59 PM, Richard Weinberger wrote:
> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
>> Hello All:
>>
>> I am a hardened gentoo user. How can we get the grsecurity code into the
>> kernel?
> 
> As soon all downsides and drawbacks are identified/resolved.
> Which basically means that we have to redo a lot (it not all).

You might not be familiar with the grsecurity/PaX features and their
implementations but lots of people are. It's not unexplored territory
without known trade-offs. It has active developers who are happy to
answer questions about it (within reason).

I think there's little that would need to be redone. There are many
things that would need to be renamed and refactored in order to present
them in a different light to deal with political issues. One good way to
upstream stuff would be presenting it from the angle that it's useful
for finding kernel bugs for *everyone* and just accepting that some of
it is going to be misrepresented (i.e. CONFIG_DEBUG_*).

Approaching this as if it's a technical issue is only going to lead to
failure. I really can't see Linus and others being okay with any GCC
plugins with alterations to the semantics of C rather than just codegen
like the KERNEXEC plugin. Dropping time into extracting stuff like that
rather than realistic things seems wasteful. If someone puts in the
effort to do it, submits it and hits a wall then I wouldn't expect them
to be motivated to do more.

I think there's plenty that could be landed but going directly upstream
may not be the way to go. I was considering spending time on doing most
of the small features and submitting them to AOSP. No politics to deal
with there, only technical issues. If something lands there, it becomes
a lot easier to upstream it because it becomes part of trying to get
Android to use a vanilla kernel. Android wants security features and
Linux isn't delivering, so it might as well start diverging more. For
example, they recently started improving their ASLR implementation
towards matching PaX (not there yet). I'm sure they'd take features like
USERCOPY as-is.


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

Re: [kernel-hardening]

[Daniel Micay]

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

> I really can't see Linus and others being okay with any GCC
> plugins with alterations to the semantics of C rather than just codegen
> like the KERNEXEC plugin.

Oh and REFCOUNT is basically the same situation. I can't see any
possibility of that landing without switching to having a refcount_t
type and having separate functions for working with it, with a
configuration option like DEBUG_REFCOUNT to flip on overflow checks.
It's a whole bunch of busy-work and since it will touch so much code it
will run into the same problems that the previous attempts to upstream
constification did.


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

Re: [kernel-hardening]

[David Windsor]

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

I'm currently in the process of preparing my earlier PAX_REFCOUNT patch set
for resubmission, and I tend to agree with you - I'm not very hopeful of
Linus, et al accepting them.  But, we will try again.

With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
overflow protection to the already existing atomic_t type, and creates a
new type, atomic_unchecked_t, for non-reference-counter types (i.e.
statistical counters).

On Mon, Nov 16, 2015 at 12:45 AM, Daniel Micay <danielmicay@gmail.com>
wrote:

> > I really can't see Linus and others being okay with any GCC
> > plugins with alterations to the semantics of C rather than just codegen
> > like the KERNEXEC plugin.
>
> Oh and REFCOUNT is basically the same situation. I can't see any
> possibility of that landing without switching to having a refcount_t
> type and having separate functions for working with it, with a
> configuration option like DEBUG_REFCOUNT to flip on overflow checks.
> It's a whole bunch of busy-work and since it will touch so much code it
> will run into the same problems that the previous attempts to upstream
> constification did.
>
>

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

Re: [kernel-hardening]

[Richard Weinberger]

On Mon, Nov 16, 2015 at 6:33 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 15/11/15 03:59 PM, Richard Weinberger wrote:
>> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
>>> Hello All:
>>>
>>> I am a hardened gentoo user. How can we get the grsecurity code into the
>>> kernel?
>>
>> As soon all downsides and drawbacks are identified/resolved.
>> Which basically means that we have to redo a lot (it not all).
>
> You might not be familiar with the grsecurity/PaX features and their
> implementations but lots of people are. It's not unexplored territory
> without known trade-offs. It has active developers who are happy to
> answer questions about it (within reason).

I'll kindly ignore this personal attack.

> I think there's little that would need to be redone. There are many
> things that would need to be renamed and refactored in order to present
> them in a different light to deal with political issues. One good way to
> upstream stuff would be presenting it from the angle that it's useful
> for finding kernel bugs for *everyone* and just accepting that some of
> it is going to be misrepresented (i.e. CONFIG_DEBUG_*).
>
> Approaching this as if it's a technical issue is only going to lead to
> failure. I really can't see Linus and others being okay with any GCC
> plugins with alterations to the semantics of C rather than just codegen
> like the KERNEXEC plugin. Dropping time into extracting stuff like that
> rather than realistic things seems wasteful. If someone puts in the
> effort to do it, submits it and hits a wall then I wouldn't expect them
> to be motivated to do more.
>
> I think there's plenty that could be landed but going directly upstream
> may not be the way to go. I was considering spending time on doing most
> of the small features and submitting them to AOSP. No politics to deal
> with there, only technical issues. If something lands there, it becomes
> a lot easier to upstream it because it becomes part of trying to get
> Android to use a vanilla kernel. Android wants security features and
> Linux isn't delivering, so it might as well start diverging more. For
> example, they recently started improving their ASLR implementation
> towards matching PaX (not there yet). I'm sure they'd take features like
> USERCOPY as-is.

Sorry, I'm not that optimistic as I had already the pleasure to port various
PaX/grsecurity features and also tried to mainline some bits.

But I'm eager to read your patches and will happily contribute.

-- 
Thanks,
//richard

Re: [kernel-hardening]

[Daniel Micay]

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

On 16/11/15 01:38 AM, David Windsor wrote:
> I'm currently in the process of preparing my earlier PAX_REFCOUNT patch
> set for resubmission, and I tend to agree with you - I'm not very
> hopeful of Linus, et al accepting them.  But, we will try again.
> 
> With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
> overflow protection to the already existing atomic_t type, and creates a
> new type, atomic_unchecked_t, for non-reference-counter types (i.e.
> statistical counters).

Yeah, I'm aware it does it that way. The problem is that it would have
to be done the other way around for it to land upstream (realistically).

Doing it the only way around would be involve too many changes so it
wouldn't be feasible to land everything, but the positive side of it is
that the changes could be landed bit by bit (i.e. one set of refcount
fields at a time).


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

Re: [kernel-hardening]

[Kees Cook]

On Sun, Nov 15, 2015 at 9:33 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 15/11/15 03:59 PM, Richard Weinberger wrote:
>> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
>>> Hello All:
>>>
>>> I am a hardened gentoo user. How can we get the grsecurity code into the
>>> kernel?
>>
>> As soon all downsides and drawbacks are identified/resolved.
>> Which basically means that we have to redo a lot (it not all).
>
> You might not be familiar with the grsecurity/PaX features and their
> implementations but lots of people are. It's not unexplored territory
> without known trade-offs. It has active developers who are happy to
> answer questions about it (within reason).
>
> I think there's little that would need to be redone. There are many
> things that would need to be renamed and refactored in order to present
> them in a different light to deal with political issues. One good way to
> upstream stuff would be presenting it from the angle that it's useful
> for finding kernel bugs for *everyone* and just accepting that some of
> it is going to be misrepresented (i.e. CONFIG_DEBUG_*).
>
> Approaching this as if it's a technical issue is only going to lead to
> failure. I really can't see Linus and others being okay with any GCC
> plugins with alterations to the semantics of C rather than just codegen
> like the KERNEXEC plugin. Dropping time into extracting stuff like that
> rather than realistic things seems wasteful. If someone puts in the
> effort to do it, submits it and hits a wall then I wouldn't expect them
> to be motivated to do more.

That's precisely what my Kernel Summit presentation was doing: trying
to convince people that we need to look beyond just bugs, and to
accept the technical burden of these features (and their
infrastructure) the protect end-users. I think a lot of developers are
more convinced of that now, which is why this project exists. I don't
think our time is wasted any more: we can address the technical issues
finally, without having to fight as hard a social battle to see them
upstreamed.

> I think there's plenty that could be landed but going directly upstream
> may not be the way to go. I was considering spending time on doing most
> of the small features and submitting them to AOSP. No politics to deal

AOSP isn't enough, and even if people did submit them there, I would
be one of the AOSP reviewers asking that they be upstreamed instead.
;)

> with there, only technical issues. If something lands there, it becomes
> a lot easier to upstream it because it becomes part of trying to get
> Android to use a vanilla kernel. Android wants security features and
> Linux isn't delivering, so it might as well start diverging more. For
> example, they recently started improving their ASLR implementation
> towards matching PaX (not there yet). I'm sure they'd take features like
> USERCOPY as-is.

Sure, but those userspace ASLR improvements are being developed
_upstream_. They started their life as a proof-of-concept in AOSP, but
I (and others) who reviewed it there asked that it be taken upstream
first.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening]

[Kees Cook]

On Sun, Nov 15, 2015 at 10:38 PM, David Windsor <dave@0x4141.net> wrote:
> On Mon, Nov 16, 2015 at 12:45 AM, Daniel Micay <danielmicay@gmail.com>
> wrote:
>>
>> > I really can't see Linus and others being okay with any GCC
>> > plugins with alterations to the semantics of C rather than just codegen
>> > like the KERNEXEC plugin.
>>
>> Oh and REFCOUNT is basically the same situation. I can't see any
>> possibility of that landing without switching to having a refcount_t
>> type and having separate functions for working with it, with a
>> configuration option like DEBUG_REFCOUNT to flip on overflow checks.
>> It's a whole bunch of busy-work and since it will touch so much code it
>> will run into the same problems that the previous attempts to upstream
>> constification did.
>>
> I'm currently in the process of preparing my earlier PAX_REFCOUNT patch set
> for resubmission, and I tend to agree with you - I'm not very hopeful of
> Linus, et al accepting them.  But, we will try again.

When you've got it ready, let's review it here first. I've had a lot
of experience navigating the upstreaming of unpopular things. :) We
can bikeshed and test it on this list first, and then when we think
it's ready, we can send it upstream.

> With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
> overflow protection to the already existing atomic_t type, and creates a new
> type, atomic_unchecked_t, for non-reference-counter types (i.e. statistical
> counters).

I'm looking forward to testing this! I was pondering a quick and dirty
LKDTM test to validate the results, too. Did you have anything already
designed to test it?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening]

[Kees Cook]

On Mon, Nov 16, 2015 at 2:03 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 16/11/15 01:38 AM, David Windsor wrote:
>> I'm currently in the process of preparing my earlier PAX_REFCOUNT patch
>> set for resubmission, and I tend to agree with you - I'm not very
>> hopeful of Linus, et al accepting them.  But, we will try again.
>>
>> With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds
>> overflow protection to the already existing atomic_t type, and creates a
>> new type, atomic_unchecked_t, for non-reference-counter types (i.e.
>> statistical counters).
>
> Yeah, I'm aware it does it that way. The problem is that it would have
> to be done the other way around for it to land upstream (realistically).

I may be proven wrong in the end, but I totally disagree with you. :)
I think it is valuable to _start_ from a position of protecting the
atomics and then marking those that don't care about overflow (they
are the minority). We should take a stance of whitelist not blacklist
for these features.

> Doing it the only way around would be involve too many changes so it
> wouldn't be feasible to land everything, but the positive side of it is
> that the changes could be landed bit by bit (i.e. one set of refcount
> fields at a time).

We'll see what it looks like, but I think we start by gaining the
protection and people that don't want it can fix it on a case-by-case
basis. I may be naive, but I think it's probably the best place to
work from initially.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [kernel-hardening]

[Daniel Micay]

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

On 16/11/15 07:13 AM, Richard Weinberger wrote:
> On Mon, Nov 16, 2015 at 6:33 AM, Daniel Micay <danielmicay@gmail.com> wrote:
>> On 15/11/15 03:59 PM, Richard Weinberger wrote:
>>> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
>>>> Hello All:
>>>>
>>>> I am a hardened gentoo user. How can we get the grsecurity code into the
>>>> kernel?
>>>
>>> As soon all downsides and drawbacks are identified/resolved.
>>> Which basically means that we have to redo a lot (it not all).
>>
>> You might not be familiar with the grsecurity/PaX features and their
>> implementations but lots of people are. It's not unexplored territory
>> without known trade-offs. It has active developers who are happy to
>> answer questions about it (within reason).
> 
> I'll kindly ignore this personal attack.

I didn't mean this as a personal attack. I just found that statement to
be off i.e. it seems to imply that PaX/grsecurity are low quality and
that they need to be improved to upstream them, when IMO what really
needs to happen to just making the features more politically acceptable
even if it ends up making them harder to implement / less useful.


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

Re: [kernel-hardening]

[Daniel Micay]

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

> AOSP isn't enough, and even if people did submit them there, I would
> be one of the AOSP reviewers asking that they be upstreamed instead.
> ;)

Sure, but it's a way to proving to upstream that the features are useful
and work well. For example, lets say x86 Android adopted the
segmentation-based KERNEXEC/UDEREF. Lets say it actually shipped in the
next version of Android. I am pretty sure Linus would change his
attitude towards it. You're not going to convince him by words rather
than actions though. Not that improving Linux on a dying architecture
should be the priority, but it's a good example.


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

Re: [kernel-hardening]

[Richard Weinberger]

On Tue, Nov 17, 2015 at 8:41 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> On 16/11/15 07:13 AM, Richard Weinberger wrote:
>> On Mon, Nov 16, 2015 at 6:33 AM, Daniel Micay <danielmicay@gmail.com> wrote:
>>> On 15/11/15 03:59 PM, Richard Weinberger wrote:
>>>> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.com> wrote:
>>>>> Hello All:
>>>>>
>>>>> I am a hardened gentoo user. How can we get the grsecurity code into the
>>>>> kernel?
>>>>
>>>> As soon all downsides and drawbacks are identified/resolved.
>>>> Which basically means that we have to redo a lot (it not all).
>>>
>>> You might not be familiar with the grsecurity/PaX features and their
>>> implementations but lots of people are. It's not unexplored territory
>>> without known trade-offs. It has active developers who are happy to
>>> answer questions about it (within reason).
>>
>> I'll kindly ignore this personal attack.
>
> I didn't mean this as a personal attack. I just found that statement to
> be off i.e. it seems to imply that PaX/grsecurity are low quality and
> that they need to be improved to upstream them, when IMO what really
> needs to happen to just making the features more politically acceptable
> even if it ends up making them harder to implement / less useful.

Well, it is of course not of low quality. Nobody said that.
But some features have a technical burden and performance drawbacks.
These need to be explained in detail and I'm sure there is also room for
improvement.

Anyway, enough hot air for now. Patches talk, bullshit walks. ;-)

-- 
Thanks,
//richard

Re: [kernel-hardening]

[Kees Cook]

On Tue, Nov 17, 2015 at 12:09 AM, Daniel Micay <danielmicay@gmail.com> wrote:
>> AOSP isn't enough, and even if people did submit them there, I would
>> be one of the AOSP reviewers asking that they be upstreamed instead.
>> ;)
>
> Sure, but it's a way to proving to upstream that the features are useful
> and work well. For example, lets say x86 Android adopted the
> segmentation-based KERNEXEC/UDEREF. Lets say it actually shipped in the
> next version of Android. I am pretty sure Linus would change his
> attitude towards it. You're not going to convince him by words rather
> than actions though. Not that improving Linux on a dying architecture
> should be the priority, but it's a good example.

Right, that's absolutely a potential path to keep open. It's
effectively what happened to things like Binder. Each piece is going
to be a little different. UDEREF is (politically still) a hard sell on
x86, but arm now has CONFIG_CPU_SW_DOMAIN_PAN that covers a fair bit
of non-LPAE-arm UDEREF. (I await spender's flames now...)

So, the more we split out and test, the better. :)

-Kees

-- 
Kees Cook
Chrome OS Security