Live data from Hacker News

Passing the Baton

grsecurity.net

31–40 of 82 posts

Re: Passing the Baton

#31

Earlier quoted context omitted.

Are you serious? If yes, ask PAX Team, irc email, whatever.

You mean the freemail.hu email on a page that only appeared about a year after their last release?

Please don't do that, this is not Reddit, I'm sure you'll figure a way out to contact PAX Team.

Re: Passing the Baton

#32
post #7

Earlier quoted context omitted.

Why are the grsecurity patches not included in the Vanilla Kernel? https://unix.stackexchange.com/questions/59020/why-are-the-g...

In other words: nobody ever tried to get it into mainline. Anyone reading this right now could go and get it submitted into mainline in the chunks that Linus would accept. It would take about 6 months, though, assuming you knew what you were doing.

Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They have very specific "chunks" of functionality which are quite invasive, by design. This goes against the model the Linux kernel is developed, so the two development communities are simply mutually exclusive.

https://www.linux.com/news/google-developer-kees-cook-detail...

He's been working on this for a very long time.

Re: Passing the Baton

#33

Earlier quoted context omitted.

You mean the freemail.hu email on a page that only appeared about a year after their last release?

Please don't do that, this is not Reddit, I'm sure you'll figure a way out to contact PAX Team.

Don't do what exactly?

Re: Passing the Baton

#34
post #29

How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?

grsec has had a commercial program for a while. The way these things tend to work is "It's GPL, but if you redistribute it publicly we terminate your subscription with no refund." (I think RHEL binaries work the same way, for instance.) The reason for companies to pay is to get reliable updates for new versions, so that they can avoid hiring a bunch of people in-house to build / forward-port things. So usually this i…

RHEL binaries are, well, binaries. A patchset like grsec is source. I don't think RHEL restricts source redistribution, which they seem to release publicly anyway.

Re: Passing the Baton

#36
post #6

Earlier quoted context omitted.

Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applie…

That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfr…

> It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all.

Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at least if it's e.g. purely positional to elide context related issues). The result of applying the patch would not be distributable, but I'd think the patch itself would be fine.

Re: Passing the Baton

#37

I suspect this will just shift focus to the Kernel Self Protection Project[1]. It may end up being the best thing that could have happened for kernel security in the end. [1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

Could KSPP evolve to add missing features that are currently present in grsecurity?

https://grsecurity.net/compare.php

Re: Passing the Baton

#38

Earlier quoted context omitted.

Don't do what exactly?

Push your conspiracy teories.

It's no conspiracy theory that Brad both claims to not be paxteam, but has no problem making accounts with the username paxteam when he argues in comment threads.

Also, pedantically, this wouldn't be a 'conspiracy theory', since all I'm suggesting is that one guy is being disingenuous​ on the internet.

Re: Passing the Baton

#39
post #3

I love how grsecurity is always quick to point out how generous they have been by providing the patches for free. > We have been providing grsecurity freely for 16 years. Meanwhile the kernel upon which their work is built has been provided for free for much longer, and continues to be.

you conveniently forgot to mention the fundamental difference: the upstream kernel isn't developed for free whereas our code has always been. changes the equation quite a bit, doesn't it?

Re: Passing the Baton

#40
post #16

Earlier quoted context omitted.

PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.

Every post on lwn or mailing lists by "PaXTeam" is quite obviously spender with another handle.

i think you're 'quite obviously' wrong ;).
Post reply on HN