Important Notice Regarding Public Availability of Stable Patches
grsecurity.net
grsecurity.net
Here's the forum post on backporting an EFI fix:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3713
And products with Wind River Linux prominently mentions GRSecurity advertisements:
https://www.google.com/search?q=wind+river+linux+grsecurity
Edit: It looks like I wasn't the only one to find this. I'll keep this post at the top for other people to reply to.
To add insult to injury, the subsidiary released a hardware product years later and another company released a similar but different product in the same segment. The subsidiary sued the other company and had this PR story published about how the CEO was so offended by the "theft" and had to sue them to be able to look his kids in the face.
People violating the GPL usually aren't intermediaries. If they don't get the safe harbor to begin with then they can't lose it by not following the takedown process.
I wonder if an intermediary could be found though. If an infringer is hosting their website on AWS, what happens when somebody sends a takedown notice to Amazon?
https://www.eff.org/issues/intellectual-property/guide-to-yo...
It's great that groups like the FSF and Software Freedom Conservancy are using their funds to support legal action when necessary, but they can't be everywhere and enforce everything.
And the whole contingency thing... a lot less common than you think. Speaking as someone that's had his copyright ripped off multiple times and been injured due to negligence by the city of New York and/or Amtrak and looked into it with multiple attorneys in each case.
For the most part, the legal system serves those with means and those with means alone.
Every time and again I read news about some photographer than sued some company and got a million or so for the efforts. Its not easy, quite expensive and I guess many author do give up rather than push forward, but there is recourse against huge companies that violate copyright. The good thing about such lawsuits is that the burden of proof for having a license sits on the infringer, which means a judge don't actually need to understand that fine details of software licenses in order to find someone guilty of infringement.
As JohnTHaller said: "For the most part, the legal system serves those with means and those with means alone."
As you said: "Its not easy, quite expensive..."
"that way" which I said it worked, was for non-profits and hobbyist, and so was the comment I was replying to, so yes, it does work that way.
> those with means and those with means alone.
Your own comment explained says that it works for other people.
I've asked sfconservancy and fsf for help, but they wouldn't take the case.
http://global.verifone.com/products/software/v-os/ - Says its Linux Based.
http://www.verifone.com/products/hardware/multimedia/ - Have an MX 900 series of products.
http://www.verifone.com/products/hardware/petro-pos-systems/ - Have a Petro series of Products
NYSE:PAY - are a multi-billion dollar company.
Employee asking for help: https://forums.grsecurity.net/viewtopic.php?f=3&t=3938&p=139...
GRsec saying its verifone: https://twitter.com/grsecurity/status/450995354972864513
Thread indicating they are using an old unmaintained kernel: https://twitter.com/grsecurity/status/424914478912651264
Industry called out specifically: "Not only has the entire embedded industry as a whole not contributed a single dime toward our continued development and maintenance (despite our work being critical to the security of the millions of devices using our code: streaming media players, credit card processing systems, etc), the companies we've identified have actively violated the GPL and even our trademark. These transgressions have continued despite their awareness and our legal action."
Yeah, uh, they're lawyers, they always say that, it's not a signal with any information in it.
As you said, this company can outspend you, and it's not worth it for you to try litigating. Public shaming is all you have! And, since the primary issue was them claiming their kernel has "grsecurity", public shaming is actually a great solution: try to make the technical community aware that this company's security hardening doesn't deserve the "grsecurity" description. You may even get more business from competitors who want to be able to say they worked with you on their grsecurity integration.
That way they said it, without actually saying it.
To Brad and the PaX team directly (if you read this): You do incredible work and I sincerely hope this move leads to an inundation of sponsorship so that even more people can benefit from your hard work and innovation. Till then, know that there are those of us that stand behind you 100 percent!
volunteers shouldn't be shelling out thousands in copyright and licensing violations- even if they won in court, the amount awarded back would probably be a pittance compared to what these manufacturers make by using their code/trademarks.
I love what the pax guys do, almost every major exploit in the last year is mitigated in some form by grsec.. I wonder what becoming a sponsor entails.. I mean, I wish I could support all the FOSS I use, but I'd go broke pretty quick. :(
Yeah I seem to have that a lot as well.
What I figured a while ago, in summary, is this: we will always use more than we can contribute back. As a silly example, I am grateful for the invention of the wheel but in no way could I pay someone back (living or dead) for every single thing like that. The important thing is that we do something. Contribute either with time and skill or with money to a few projects you care about and which you feel can actually use your help. That's still tricky, though, I wouldn't know which of the 2100 installed apt-get packages need my support the most, but realizing this (rather than feeling indebted) gives me some peace of mind.
(If anyone cares, I actually blogged about this: http://lucb1e.com/?p=post&id=121 )
If a project releases open source totally for free, it cannot realistically expect sponsorship to magically appear.
If a project needs sponsorship to keep the lights on, the we're closing up shop, unless ... routine works.
If a project prefers to become a commercial product with a freemium option, they should do such.
Otherwise, don't slave away on a project and resent what you cannot afford to give away. Just don't do it, if you can't live with it being exploited by companies for free.
Punishing everyone for the sin of a few rogue companies is the kindergarteners routine and childish. It doesn't work and it just angers people without solving the licensing issue at a core level.
PS: Perhaps grsecurity may want to instead consider a sensible noncommercial license similar to somewhere between AGPL and something like what good ol' evil Oracle would license their DBMS, i.e., companies over X employees or Y revenue need a license; hobbyists, academics and individual developers exempted. Drama resolved.
Being a set of Linux patches, it would be hard for them not to make their code available under GPLv2.
They can do the Red Hat thing of making code available only to paying customers, and terminating their customers' accounts if they redistribute things publicly. They mention that in the post.
The real problem here is not companies abusing the GPL (good luck with that), but grsecurity not being integrated with mainline after more than a decade.
You see, if Spender really cared about security he would work with the kernel developers in order to get grsecurity into the kernel but of course being such a famewhore, he never did that. Everything is fine as long as he is the center of attention, actual security be damned.
Spender: I among many have little sympathy for you, you've long exhausted our patience with your antics. Grsecurity is a niche project with minimal actual security impact in the "real world", all because of the deranged way you choose to manage it. Your primary concern, your _ONLY_ concern should be getting grsecurity into the kernel, not companies ripping you off, not companies abusing your trademark, not companies "not playing nice". In the grand scheme of things, these are irrelevant.
Oversized egos are a problem at the best of times in open source, especially in the kernel. Which has traditionally had a culture of casual indifference toward the security priorities of PaX/grsec, and some would say toward security generally (I don't buy that - there's a lot of concern for integrity in the kernel, and that at least buys you some security).
Whilst it would have been great if Spender could have completely changed his personality, outlook and perspective on the world so that he could commandeer the linux kernel from the outside-in toward his vision of a safer kernel, is that really compatible with the wider project? And so, it's equally depressing there hasn't been more recruitment from the kernel side - the side that actually has resources - to figure out a path toward getting PaX stuff mainlined from the inside-out.
I guess my point is: grsec has one focus, one priority. But the Linux kernel is a project that has a much more vast, broader scope of competing priorities to untangle, and I just can't see that such an enormous, busy and byzantine project ecosystem truly will ever see a clear mandate to get something as disruptive and single-minded as grsec mainlined.
Not only would Spender have to become a different person, but the core kernel teams as well.
In any case, I've reduced my patreon donations and put what little that is towards grsecurity. It's certainly that important and useful to me.
The test series, unfit in our view for production use, will however continue to
be available to the public
This is such a shit situation to be in. Hopefully this publicity gains them some traction with the companies and communities who do care about it.
Since grsecurity is GPL'd (being modifications to the GPL'd kernel), anyone that is "a customer of any product that uses grsecurity in binary form, [is] entitled to the complete corresponding source code." Which means their stable patches will get requested and released by someone anyway.
Help me understand how this will have any effect on the actual availability of their stable series?
Since they don't distribute it, they also don't distribute the patches.
And even still, they could re-distribute the grsecurity code if they wanted to. But they probably won't bother. So yes this private-patches policy will have a big impact on availability, at least on convenience.
Really, it's just weakening the brand they've created for themselves. It always sounds really great in theory, but it's almost never worth it. It's the GPL, they've literally signed up for this type of code (ab)use. I'm not sure why people have trouble understanding this concept.
(Though if they wanted to be really snarky, they'd relicense their code GPLv3 and watch these companies go into complete hysterics.)
The GRsec people wouldn't care, their patch can be whatever GPLv2-compatible license it wants to be.
> Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
(emphasis mine) Is it legal to penalize someone for exercising their redistribution rights, or would that count as a de facto restriction?
Further restrictions probably aren't introduced if they packaged this the right way i.e. not bind the GPL license with whatever agreement they will come up with. Sponsors will still have the same rights they are now used to, but GPL never speaks obligations on the distributor having to provide updated versions.
Licensing code under the terms of the GPL does not constitute signing up for trademark infringement. The article's primary focus was on trademarks, as it should be. Nowhere did the authors claim that this vendor was violating the terms of their code license.
"the companies we've identified have actively violated the GPL and even our trademark."
Did you read the announce? https://grsecurity.net/announce.php
How is that unfair to them specifically? The purpose of this is to protect them by raising a paywall for anyone that isn't their 'sponsor'? (tangentially, that's why I prefer BSD/MIT, because people aren't as obsessed with other people doing dirty, nasty things with their free code.)
It's bad enough that these patches aren't integrated into the kernel like they ought to be or that they aren't included into mainline distros and are only ever present on custom built machines, now they are behind paywall as well. Damit, I don't want to move to OpenBSD.
Why not? OpenBSD's awesome.
Why would you have to migrate to OpenBSD? Is the test series unstable?
Does your laptop have an Nvidia GPU, by chance? In my experience, those do tend to have very bad performance on OpenBSD. Intel and AMD/ATI GPUs should work better.
Also, it's worth mentioning that OpenBSD's kernel has a whole slew of debugging and error checking features compiled in by default; compiling a custom kernel without such features can be done, but the docs don't really recommend it, since it becomes excruciatingly difficult to troubleshoot any problems with it.
You are free to be surprised all you wish: I went back to linux because I was sick of dealing with the system locking up for 5-10 seconds every time I opened, closed, or switched to a new browser tab. Couple that with 1-2 fewer hours' worth of battery life and I found myself very quickly asking what the point of "code correctness" was if the system just doesn't work.
A thoroughly frustrating experience from top to bottom.
We would consider OpenBSD if it ran on AWS and stably supported ZFS. (We use FreeBSD with PF and ZFS.)
"NIH syndrome" resulted in signify rather than using normal, proven tools like GPG which Debian-base distros use for package management.
It probably could if Amazon wanted to support it. It does already run on Xen (which is what AWS is built on, IIRC).
> "NIH syndrome" resulted in signify rather than using normal, proven tools like GPG
Whoa there, pardner! Let's not be so quick to label every attempt at improving the selection of software in a given category as "NIH syndrome", eh? By that logic, "NIH syndrome" resulted in GnuPG rather than using normal, proven tools like the original PGP :)
GnuPG is great. Don't get me wrong. I use it all the time, even on OpenBSD. GnuPG is also a big program. It has a lot of features, and tends to be very complex. In the context of package signing, most of those features - like encryption, webs of trust, all that jazz - are way overkill; the OpenBSD folks just needed a tool that can apply a digital signature and verify that signature, and signify does that job pretty darn well.
There's also the fact that GnuPG is GPL-licensed, and OpenBSD has a pretty strict policy against including copyleft software. The implications of copyleft might not be important to you or me or the dog next door, but they're very important for the OpenBSD folks.
Re: package signing: yes, this was a strange oversight, and I'm glad they sign their packages now.
> Then there is limited choice of packages
It's not that limited, at least on i386 and AMD64 (other platforms are a bit more limited). Are there particular packages that are missing that you'd prefer to be available?
> and I don't trust randomers maintaining them.
So compile them yourself, with or without ports. OpenBSD ships with GCC, binutils, etc. Besides, I'm pretty sure this is the same situation as with Gentoo, Arch, etc. (and know for a fact that it's the same situation as Slackware's SlackBuilds.org).
> In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them
I run multiple OpenBSD servers. I can personally attest that the effort required to maintain them is minimal.
The only situation where OpenBSD maintenance is less than dead simple is when it comes to upgrading a machine where you don't have console access (such as a server in a remote datacenter), since now you have to do the installer's job yourself. When you do have console access, however, OpenBSD's installer makes it dead-simple to upgrade. Plus, it does so safely; no more total breakages like you'd get in, say, Ubuntu.
I will say, however, that it would be very nice to be able to track the stable branch without having to pretty much build OpenBSD from source. I think there are some folks that maintain stable-following ISOs, but this is really something that could and should be supported as a first-party feature.
> but it isn't prepackaged solution like Ubuntu is.
I'm pretty sure Ubuntu uses AppArmor - not grsecurity - so I'm not really sure how that's relevant in this particular discussion. Unless, of course, you happen to install grsecurity on Ubuntu, at which point I highly doubt OpenBSD not being an Ubuntu-like "prepackaged solution" is really as much of a problem as you make it out to be :)
Regardless, OpenBSD has as of late been progressing toward such a prepackaged solution. Boot the CD-ROM, mash the Enter key a few times (interrupted by entering some usernames and passwords), and you have a complete server operating system ready-to-go; a webserver or mailserver or fileserver or DNS server or timeserver or what have you is just an edit of /etc/rc.conf.local away. Maybe not a prepackaged desktop solution, there are plenty of other operating systems for that.
With that said, I'm not sure if the OpenBSD folks want to be comparable to Ubuntu. Canonical's demonstrated a willingness to compromise security and privacy for the sake of convenience (see: shopping lens), that's (hopefully) not something de Raadt and friends would want to emulate.
> companies like Verisign aren't likely to burn their CA business for anyone
Not voluntarily. You're inherently trusting some random company to be up to snuff on their security.
Because the CD-ROMs can't be intercepted and replaced, right?
That said, it's arguably easier to intercept and replace a CD-ROM traveling on the Internet than to intercept and replace a CD-ROM traveling in a padded envelope between the UK and wherever you're having it shipped to (though various entities - like U.S. customs - could do so trivially, other entities would have to go through the extra trouble of bribing customs - not impossible, but it's a barrier to entry for quite a few potential attackers). Such an interception also requires good timing, lest you be sitting around somewhere for a few days waiting for the package to arrive at the particular point in the shipping route you're waiting at.
Plus, if I remember right, the physical OpenBSD media is done using a proper CD press. While plenty of people could conceivably access such a press, that's yet another step an attacker would need to take to create a convincing forgery.
Really, though, this just highlights why software distribution is such a difficult thing to pull of securely. The ideal solution would be to drive to Calgary and pay Theo de Raadt to burn you a CD-ROM, but I'm not sure how receptive he is to houseguests :)
octave, mono, etc. The whole reason openports.se exists. It's more an outcome of how small openbsd team is so it's not intrinsically their fault, but nonetheless is something that prevents wider adoption.
> So compile them yourself, with or without ports.
And track upstream for security issues and possibly apply patches to make it work on OpenBSD and whatnot which can easily turn into 30 minute dance each day just to maintain the system. It's fine on a servers where you are paid to administer it, but it's not fine on workstation dekstops.
> the actual "blessed method" involving getting install media is actually to order a CD-ROM set
What glandium said + it's rather anachronistic to expect operating systems to arrive by mail in the age of computers.
> so I'm not really sure how that's relevant in this particular discussion.
Ubuntu has its own (numerous) flaws, but it requires less work to maintain. It was more a remark that if grsecurity becomes unavailable on servers then even if you don't run it on desktop we should start thinking about moving to other platforms out of the principle that if the system can't be hardened then it shouldn't be used.
Both of these are available as OpenBSD packages (as evidenced by running "pkg_info octave" or "pkg_info mono", assuming you have a $PKG_PATH set). No openports.se required! :)
It is similar to how any knock-off of a brand could hurt the brand; a crappier version of something that people will now associate with the real brand.
Similarly, Google presents its derivative work as Android, and it exercises its rights vigorously to defend the perception of its marque.
Obviously, I'm just pointing out the fact that there are different groups of users for both products and one group isn't likely to be influenced by how others use the trademarked goods. Android has common people for its clientele, Grsecurity has security professionals that will judge it based on its intrinsic merit and not on what some subsidiary of Intel once did with it. Grsecurity de facto doesn't need to be defended, even if de jure they are entitled to the protection. That's why this is nothing but a money grab, what bothers me though is that they try to package it into something that it is not.
https://forums.grsecurity.net/viewtopic.php?f=3&t=3713&p=134...
[1] http://www.windriver.com/products/product-overviews/PO_LINUX... [2] https://web.archive.org/web/20150403191546/http://www.windri...
"Usually it is permissible to use another person’s or company’s trademark or service mark when referring to a product or service of that person or company, provided it is clear that the mark is being used truthfully to refer to that specific product or service. It may not be used in a way that might mislead others as to that person’s or company’s affiliation with, sponsorship of or endorsement of your company or its products or services—for example, using a logo instead of simply the word form of the mark, or using the mark more prominently or frequently than necessary." [1]
This appears to be how Wind River is using it.
[1] http://www.inta.org/TrademarkBasics/FactSheets/Pages/Tradema...
Not only all that, it seems like this is a bit strange that their complaint is that they called it grsecurity without using a blessed version, so their response is to stop giving out blessed versions publicly. Won't that just encourage more companies to do exactly what they are complaining about?
It will become much harder for any company to argue the they are using grsecurity if they are not a sponsor since it is not public disseminated any more.
This should give their lawyers considerable more leverage and the offending company's lawyers are more likely to warn discourage stone walling the grsecurity team since the company will be in a weaker position.
spender just wants them to say they have an "unofficial port of grsecurity" if they're unwilling to pay for it to be done properly (i.e. a well-done port, auditing of code specific to that kernel, backporting of all relevant fixes, etc.).
Also a shame that it's probably going to be way too expensive to lawyer up something like the Firefox an RedHat style of trademark protection (where forks (or even re-compiles) must use off-label branding). :(
Also a shame that the companies in question can't even be named (and shamed)...
There, shamed. Easy.
Yes, it sucks that MegaCorp and InnoTrode are not compensating Grsecurity for the work. Its probably just as shitty that I have used grsecurity for as long as I have and just got around to donating to the project. If you use grsecurity and don't want to see it disappear go donate. Grsecurity accepts paypal/bitcoin/dwolla:
To be clear, the 'they' in that sentence are the authors of GRSecurity, not the kernel developers.
From what I heard Torvalds refuses to merge patches from folks who won't identify themselves[0], and the PaX Team refuses to reveal the membership of the team.
[0] This is a perfectly reasonable policy.
AIUI, the GRSec folks don't gain anything by keeping their patches out of tree. If they could merge them in, they should.
Someone should really break up the patchset and submit it upstream as discrete features.
Most of the time Brad is shaming kernel devs and saying they're all idiots.
(To be fair, "all" is clearly an exaggeration, but enough kernel devs are clearly writing security bugs into the kernel source tree to require an external "adult supervision" project to improve the security focus...)
Linus "I am not a nice person, deal with it" Torvalds is upset because someone else is a ranty meany about him? Heaven forbid!
Quoted below: Plainly spoken criticism of action and ideas
The real question the news articles should be asking is why the embedded
industry as a whole is scum and why everyone has problems w/ them
On the one hand I can imagine nothing more bitter than other people making money on your hard work.
However, isnt this how the whole thing goes? I mean there wouldn't be a linux kernel without the work of a whole bunch of companies. Did they get sponsorship money from you? grsecurity wouldn't exist without the work of a bunch of other people. Did grsecurity pass on money to other vendors that they rely on? What about people that wrote the drivers that grsecurity use when they did development.
Open source only works because people contribute to a shared base. In return for their contributions they get to use what others already contributed.
This is not how FLOSS is supposed to go.
If they did apply the patches AND used the grsecurity trademark in their brochures what is the problem? They arent misrepresenting grsecurity. They arent being derogatory in any way. Why can't you say that you have the kernel and you applied grsecurity patches?
It seems so funny when people are all about GPL code and "freedom" and yet act so precious about a "trademark" just like proprietary enterprises.
There _are_ no "grsecurity patches" to apply for the system they're using the grsecurity trademark on.
Seems pretty clear cut from here.
This isn't a free-speech issue -- it's just a simple acknowledgement of the fact that consumers treat names, logos, branding etc. as indicators of a product's origin, and that there's a public interest in making those indicators accurate. You can refer to the trademark as long as you don't do so in a way that misrepresents your product. In this case, unless there are specific disclaimers to the contrary, a reasonable person would think "grsecurity" means "code released and approved by the grsecurity team", instead of a version that a third party has modified.
Companies that do are essentially stealing from artisans to build infrastructure to defraud the poor so they can horde wealth.
And then donate.
For every developer or project. I don't know about most of the engineers whose work powers my internet use. How do I donate to people I don't know about?
I'm working on a product using my own port of PaX/grsecurity and I had no problem understanding and complying with spender's wishes about this.
But "[not] bother[ing] to hire us to perform the port properly for them or to actively maintain the security of the kernel they're providing to their paid customers" isn't ripping off the developers or stealing from artisans. Nor is "not contribut[ing] a single dime toward our continued development and maintenance." None of those things are required by the GPL. If you want to sell software, and if you want to get pissed when people use your software without paying you for it, choose a license that requires people to pay you for your software.
(And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.)
I'm working on an open-source product using my own port of PaX/grsecurity (as it needs to target an unsupported kernel) and I had no problem understanding and complying with spender's wishes about this.
These companies have to respect the GPL license, so they need to provide the users with the source code for their kernels.
> And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.
The grsecurity project respects the upstream trademark and licensing. In this case, they are one of the upstreams... they're not complaining about kernels not using their substantial amount of code.
They've donated a lot more mockery than money, I would think.
It's a good point.
The fact that pipacs and spender no longer spend their time pushing stuff upstream doesn't mean that upstream doesn't benefit in a huge way from grsecurity via others like Kees Cook who are willing to deal with the politics.
grsecurity doesn't violate the Linux trademark or licensing. It's not a good point at all. You wonder why they don't contribute upstream directly? It has a lot to do with this entitled attitude.