Date: Sat, 22 Dec 2018 03:09:12 -0500 From: Boris Lukashev <blukashev@...pervictus.com> To: James Hilliard <james.hilliard1@...il.com> Cc: kernel-hardening <kernel-hardening@...ts.openwall.com> Subject: Re: grsecurity updated source code Seeing how it's been a few days, a few commits into the 4.4 tree from upstream, and no statement from the grsec folks in response to this drop on this list anyway, it may be prudent to have a warning label on this patch considering it is (at least sourced from work) intended to enhance the security posture of a system: 1 - keeping these up to date is not for the faint of heart, and realistically even people doing that for their own education still use the official work in production (or base off of it). For example, rebasing the tip commit from this repo into 4.4.169 should provide for some interesting reading into the Linux codebase in everything from memory management to the KVM hypervisor, and some interesting choices for the reader at the end of it all. Getting it wrong may not be apparent at compile time, and wrong may not even be a crash but an unsafe condition affecting filesystem or memory/execution-flow protections. The effort of going through that process of figuring out "how it works" and "how to keep it working" is incredibly valuable when it produces understanding of the intent and implementation, but in terms of executable binary images, it does not produce safe/stable results suited for production use without some practice. 2 - without a trusted entity blessing the sha256sum of that commit's contents, it may be unsafe to use without full review, _especially_ in security-sensitive implementations. Searching for basic backdoors in that amount of code is already a problem (try something that leaves write holes into EFI/memory/ME/etc when wrapped with the first analysis), finding changes to compiler plugins which could weaken their functionality, compromise, or destabilize the system would require someone trusted, with verified access to the real deal (on this kernel version no less), willing to do the work, etc. 2a - even the act of compiling this should be performed in a sandboxed environment until its known to not cause harm during that process. Its still code execution. See #2 for why few people are able to confirm/deny if this patch "is real," but it is at least sourced from the real deal. The GPL seems to have worked to give the public a snapshot view of work at least derived from the grsec folks' significant efforts over the last year and a half. This is an opportunity to learn and improve the public ecosystem, not a security solution for anyone actually responsible for their/client/etc security unless they _really_ know what they're doing when working with the codebase. Nobody from Open Source Security Inc (i think that's the grsec authors official designation) asked me to write this, i actually do not have direct communication with them at all, and i have no idea how they will view these warnings. Considering their work, i assume they would also suggest everyone practice safe exec... -Boris On Tue, Dec 18, 2018 at 9:09 AM James Hilliard <james.hilliard1@...il.com> wrote: > > I've obtained and uploaded a recent grsecurity kernel here: > https://github.com/jameshilliard/linux-grsec/ > > From my understanding this is the stable patch. > > Source code was obtained from a vendor via GPL request. > > James
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.