Subject: [alpine-devel] Linus & others v. grsecurity

From: Cág <[email-masked]>
Date: Sun, 2 Jul 2017 18:37:50 +0100

Hi everyone,

I was reading news the other day and found this:
https://www.spinics.net/lists/kernel/msg2540934.html

In the comment section somebody linked this thread:
http://seclists.org/oss-sec/2017/q2/583

Bruce Perens warns about risks for grsecurity customers:
http://perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
Earlier RMS said about GPL violation.

Then there was this thing:
https://twitter.com/marcan42/status/724745886794833920
Looks like this person and some others that replied were banned by
grsecurity.

Considering the abovementioned, was it a good thing to start using
their patches? Is there a need in a hardened kernel overall?

Cheers

-- 
caóc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 6 Jul 2017 12:34:02 +0200

On Sun, 2 Jul 2017 18:37:50 +0100

> https://www.spinics.net/lists/kernel/msg2540934.html

The reason Linus calls it garbage is because its not split up, so it
cannot be included upstream:

http://www.openwall.com/lists/oss-security/2017/06/24/14

Well, Linus also says he would prefer that Spender himself sent patches
for inclusion:
  
http://www.openwall.com/lists/oss-security/2017/06/24/2

> Earlier RMS said about GPL violation.

Yeah, what they do is controversial. We don't break the GPL though.

> Looks like this person and some others that replied were banned by

They got banned from grsecurity twitter. After that grsecurity left
twitter, so he is banned from something that no longer exists.

> their patches?

When we started using their patches for more than 10 years ago, yes, it
was a good thing. They solved security issues back then that is not
solved in mainline until now. (the issue at hand that made it to media
was solved by Grsecurity around 2010-2011 something?)

They were early (first?) with ASLR. We have always built our userspace
with PIE, bindnow and relro so we can fully utilize it.

So I would definitively say it was a good thing to start using their
patches.

> Is there a need in a hardened kernel overall?

> http://seclists.org/oss-sec/2017/q2/583

Grsecurity finds and fixes many issues in kernel that nobody else
notices/cares about (until it hits media as in the recent case)

So the question is: do we need to be ahead other distros when it comes
to kernel security?

But there are some reasons to why we we should stop using it:

- It is not good to depend on something unreliable (we don't know if we
  can access future patches - there is no guarantee that they will give
  us access even if we pay them)
- No support
- It requires much work to maintain the unofficial patch
- Their business model (Alpine is open source)
- They are difficult to co-operate with

I want continue using it for as long as it is possible.

-nc

---

---

From: Cág <[email-masked]>
Date: Sun, 9 Jul 2017 16:19:24 +0100

Thanks for the answer.

-- 
caóc

---

---

From: William Pitcock <[email-masked]>
Date: Wed, 12 Jul 2017 02:18:18 -0500

Hi,

> twitter, so he is banned from something that no longer exists.

I don't think this is very interesting -- everyone by now knows the
pros and cons of interacting with Brad.

> notices/cares about (until it hits media as in the recent case)

Yes but a lot of the bugfixes they do are undisclosed, so nobody knows
about them, which is annoying.

> I want continue using it for as long as it is possible.

Personally, having looked at strcat's work, I am optimistic, and
basically I see a future where we can draw from KSPP, strcat's work,
and our own work to provide a hardened kernel for Alpine 3.7.  I'm not
too worried about it.
Ironically, strcat's work on tuning the Linux ASLR implementation
scores better on paxtest than PaX, which I found interesting.

William

---

---

From: Shiz <[email-masked]>
Date: Wed, 12 Jul 2017 09:53:07 +0200

> On 12 Jul 2017, at 09:18, William Pitcock <[email-masked]> wrote:
> 

That’s likely due to upstream not supporting UDEREF/KERNEXEC, which takes
away around 8-9 bits of entropy, IIRC.

- Shiz