[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Jun 2017 10:21:10 -0400
From: Brad Spengler <spender@...ecurity.net>
To: Daniel Micay <danielmicay@...il.com>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: Stop the plagiarism
commit 813d0df7042a8430481d245618cbab39b76876fc
Author: Brad Spengler <spender@...ecurity.net>
Date: Sat Jul 25 11:28:15 2015 -0400
Implement modify_ldt sysctl toggle from https://lkml.org/lkml/2015/7/25/103,
make it not depend on CONFIG_MODIFY_LDT_SYSCALL, force modify_ldt to off
regardless of config setting if grsec is enabled (with the allowance to
turn it on at runtime), and harden up the implementation a bit
Conflicts:
arch/x86/Kconfig
kernel/sysctl.c
It's right there in the changelogs (which you can still find online). Here's a
google cache entry for the link:
https://webcache.googleusercontent.com/search?q=cache:2IlruFKV2RIJ:https://lkml.org/lkml/2015/7/25/103+&cd=1&hl=en&ct=clnk&gl=us
I did not and have never removed someone's copyright notice and added my
own to the copy+pasted code, as is the case of what's happening here
that I'm complaining about and that I had to complain about in the past
when Intel did it.
Unlike you and the KSPP, our security reputation isn't entirely based on
the work of others. If properly crediting work is such a difficult problem
that you don't want to be bothered with, there's a very simple solution:
come up with your own ideas and write your own code!
-Brad
On Sat, Jun 03, 2017 at 09:53:47AM -0400, Daniel Micay wrote:
> > "a value linux-hardened and grsecurity have used for a long time now"
> > Rik, you're giving credit to a project that didn't even exist a couple
> > weeks ago, yet they've somehow used it "for a long time", even though
> > it only exists there because it was copy+pasted from grsecurity?
>
> You're going out of the way to misinterpret that wording.
>
> You don't document where changes came from in the PaX and grsecurity
> patches. There's code written by other people in there, and there's
> neither a Git repository crediting them in a commit history or with a
> few exceptions inline credit given to those people. When I extract
> something from the PaX or grsecurity patches or base code on the ideas
> there, I can't state with certainty who authored the code. I've been
> stating 'extracted from PaX' or 'extracted from grsecurity' for code not
> part of PaX and documenting changes from the implementation there. Code
> being from PaX or grsecurity isn't necessarily 'code authored by the PaX
> Team or Brad Spengler'. It could be code written by Emese, minipli,
> someone else who contributed code to you or a patch that you took from
> elsewhere that was ignored / rejected by upstream. How is anyone else
> supposed to know?
>
> People were given credit in the original PaX changelogs at the top of
> the patches in most cases but all but the latest patch for kernel
> branches was taken down. Similarly, the grsecurity changelogs gave
> credit but are all taken down and it's not like many people actually
> looked at those at the time.
>
> For example, the MODIFY_LDT sysctl in grsecurity is someone else's code.
> It isn't stated in grsecurity where it came from. That's true to an even
> larger extent when it comes to ideas rather than implementation. You
> give credit to Willy Tarreau for NO_SIMULT_CONNECT but not that
> MODIFY_LDT one, and I can think of a bunch of other examples.
>
> It looks to me like people contributing these changes upstream have been
> more consistently giving credit than the grsecurity patches do. When the
> grsecurity patches are not mentioning who wrote changes or came up with
> the idea how are people supposed to know who to credit... ? It applies
> to an even larger extent to ideas rather than code. Most of the code and
> ideas there are from the PaX Team and yourself, sure, but not all.
>
> Maybe stop calling me a plagiarist when I'm trying my best to give
> credit and actually do a better job than you do in practice.
>
> > Is
> > that what we do now, credit plagiarists instead of the actual authors
> > of
> > the work? Sorry, but the "work" of struggling to understand code that
> > isn't yours doesn't suddenly make it your code.
>
> These commits reference the PaX implementation there. You've told me to
> stop doing that but rather reference the specific PaX version in the
> future which I intend to do.
>
> https://github.com/thestinger/linux-hardened/commit/4c355f98910e01256ee2b01dd1a02ac08dd316b2.patch
> https://github.com/thestinger/linux-hardened/commit/711e5650589c9d3c99706c6a5d52d2659519dc74.patch
> https://github.com/thestinger/linux-hardened/commit/cd9cdbff4bc69d2e88b37d106e6ee8ef33a3a1b8.patch
>
> The Linux kernel is GPL2 and grsecurity is a derivative work. I'm not
> sure how it's plagiarism to tweak the upstream implementation of ASLR
> based on the PaX implementation while describing the differences with
> the PaX implementation which I'm trying to do in depth:
>
> Making the stack entropy depend on the mainline mmap sysctl isn't based
> on PaX and therefore doesn't reference it.
>
> I needed to move the ET_DYN base on arm64 to 4G because the address
> range overlapped when using the sysctl for the stack which I noticed in
> testing. I then did x86_64 and the 32-bit architectures. I don't know
> how the values were chosen in PaX and they don't meet the compatibility
> requirements that I need on 64-bit where there are projects using 32-bit
> pointers by mapping certain things in the lower 32 bits of the address
> space and they cannot necessarily cope with any fragmentation there.
>
> https://gist.github.com/thestinger/b43b460cfccfade51b5a2220a0550c35
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
