On Sun, 2 Jul 2017 18:37:50 +0100
Cág <ca6c@bitmessage.ch> wrote:
> Hi everyone,> > I was reading news the other day and found this:> 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> 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.
Yeah, what they do is controversial. We don't break the GPL though.
> Then there was this thing:> https://twitter.com/marcan42/status/724745886794833920> Looks like this person and some others that replied were banned by> grsecurity.
They got banned from grsecurity twitter. After that grsecurity left
twitter, so he is banned from something that no longer exists.
> Considering the abovementioned, was it a good thing to start using> 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?
I think the link you provided answers that:
> 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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi,
On Thu, Jul 6, 2017 at 5:34 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> On Sun, 2 Jul 2017 18:37:50 +0100> Cág <ca6c@bitmessage.ch> wrote:>>> Hi everyone,>>>> I was reading news the other day and found this:>> 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>>> 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.>> Yeah, what they do is controversial. We don't break the GPL though.>>> Then there was this thing:>> https://twitter.com/marcan42/status/724745886794833920>> Looks like this person and some others that replied were banned by>> grsecurity.>> They got banned from grsecurity twitter. After that grsecurity left> 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.
>> Considering the abovementioned, was it a good thing to start using>> 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?>> I think the link you provided answers that:>>> 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)
Yes but a lot of the bugfixes they do are undisclosed, so nobody knows
about them, which is annoying.
> 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.
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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
> On 12 Jul 2017, at 09:18, William Pitcock <nenolod@dereferenced.org> wrote:> > 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
That’s likely due to upstream not supporting UDEREF/KERNEXEC, which takes
away around 8-9 bits of entropy, IIRC.
- Shiz