Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#61

Post by viraptor »

SwellJoe wrote: post #22
muppetman wrote: post #17

Earlier quoted context omitted.

What about grsecurity do you consider to be snake oil? A couple of times the grsecurity patch has prevented a machine of mine being exploited - the first time the exploit didn't work at all and the second grsecurity added enough protection that the kernel crashed and rebooted. I consider both Brad and PaX Team to be very clever people (though you could easily argue I'm biased as I use the grsecurity patch, confirmati…

As I said, I think there are some good ideas in grsecurity. But, I am mistrustful of something built by a small team without outside vetting, particularly when it comes to security sensitive code. The "snake oil" part is that somewhere along the way, a significant segment of a huge industry has been convinced that features that are standard in the current Linux kernel are only possible with grsecurity. We get feature…

> built by a small team without outside vetting

Unfortunately "small team" as in giving us their private time, describes lots of security-relevant software we're using every day. GPG was a recent example in need of funding.

I'm not sure what you mean by no vetting though. There's quite a bit of discussion related to grsec. A small team is a small team - it doesn't need to be a corporation to work. It may actually work well because it's a small team.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#62

Post by sigjuice »

mkl wrote: post #28
protomyth wrote: post #16

Earlier quoted context omitted.

If what you say is true, and I have no doubts you are correct, then how is Red Hat's kernel policy different from Grsecurity? They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination. I'm not asserting bad / good. I'm would like to know the difference.

If I understand it correctly, you can distribute Red Hat's source all you want, but it's up to you to figure out which bits of the kernel that is. That extra information is not part of the code.

What is the "extra information" in this context?

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#63

Post by drewcrawford »

chx wrote: post #50
drewcrawford wrote: post #43

Earlier quoted context omitted.

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

You are talking nonsense. The only "right to free speech" there is > Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech This is fundamentally different from the GPL situation. Much closer is intimidation which is recognized as a criminal offense in many US states.

You are talking nonsense. The "right to free speech" in the United States has developed over hundreds of years of jurisprudence. It is impossible to summarize here but for starters involves not only Congress but also states (Gitlow v NY) and even private parties (Snyder v. Phelps). I don't mean to suggest it is arbitrarily broad but it is certainly much broader than to say it is "only" the text of the first amendment.

Secondly, "intimidation" carries a very specific legal meaning, for example here's the Montana statute [0]:

    (1) A person commits the offense of intimidation when, with the purpose to cause another to perform or to omit the performance of any act, the person communicates to another, under circumstances that reasonably tend to produce a fear that it will be carried out, a threat to perform without lawful authority any of the following acts: 

     (a) inflict physical harm on the person threatened or any other person; 
     (b) subject any person to physical confinement or restraint; or 
     (c) commit any felony.
Unless GRSecurity is threatening to break your legs, kidnap you, or rob your store, they are not intimidating you.

What we are talking about is refusing to do business with you, which is very legal. There are some exceptions, such as if the basis for that refusal is due to your race/sex, or if GRSecurity is a cartel, or if they are refusing in order to obstruct an investigation into some other illegal activity, but I'm not aware of those kinds of facts here.

[0] http://leg.mt.gov/bills/mca/45/5/45-5-203.htm

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#64

Post by SwellJoe »

simcop2387 wrote: post #58

I've got a question about this whole GPL enforcement issue. Scenario: I'm a VPS company, I provide my customers with kernels compiled with GRSec. I provide a number of modules for different protocols, nftables, etc. with the custom kernels i've built for the VMs. Under the GPL I have to provide the patched source of all those modules (and kernel If I provide that image too) to my customer. Question: With GRSec's repo…

That's a big part of the implication of this post, I think.

Grsecurity heavily markets itself to the multi-tenant hosting industry. Thus, your scenario is a big part of their customer base. So, if these allegations are true, then not only is grsecurity violating the GPL, they're demanding their customers violate the GPL, too.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#65

Post by drewcrawford »

SwellJoe wrote: post #57
drewcrawford wrote: post #45

Earlier quoted context omitted.

> Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it Of course they prohibit it. e.g. from [1] > This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement…

Your first quote covers trademarks. That is unrelated to source code. CentOS ships with a different set of trademarks. If you want to rebuild and redistribute the RH sources, you remove the trademarks. That's well understood and well within the terms of the GPL. Second refers to binary builds of the software. Also well within the terms of the GPL. Third refers to the Subscription Service which includes access to bina…

> Your first quote covers trademarks. That is unrelated to source code.

Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement.

You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#66

Post by drewcrawford »

gizmo686 wrote: post #60
drewcrawford wrote: post #43

Earlier quoted context omitted.

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

In the US, your only "right" to free speech is protection from the government restricting your speech. Indeed, if your employer is the government, then there are significant (but not absolute) limitations on how much they can retaliate for your speech.

No, you also have a right to free speech against private actors (in certain circumstances). For one example, see Snyder v. Phelps.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#67

Post by SwellJoe »

drewcrawford wrote: post #65
SwellJoe wrote: post #57

Earlier quoted context omitted.

Your first quote covers trademarks. That is unrelated to source code. CentOS ships with a different set of trademarks. If you want to rebuild and redistribute the RH sources, you remove the trademarks. That's well understood and well within the terms of the GPL. Second refers to binary builds of the software. Also well within the terms of the GPL. Third refers to the Subscription Service which includes access to bina…

> Your first quote covers trademarks. That is unrelated to source code. Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement. You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.

I'm not interested in re-litigating the trademark discussion here. It's not relevant to the grsecurity conversation, and it's been settled for a decade or so. Trademark law is separate from copyright law and really has no place in a copyright discussion.

Red Hat places branding in their own packages, generally, which is easily replaced by distributions...they do their own re-branding in Fedora and CentOS; the trademarks are built to be removable. Red Hat went out of their way to make it easier to build a from-source RHEL without violating trademarks, despite not really having a legal obligation to do so.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#68

Post by nisa »

bcoates wrote: post #46
nisa wrote: post #35

Earlier quoted context omitted.

If you are on shared hosting or any kind of machines that depends on the kernel to enforce permissions any kernel hole means ability to rootkit the whole thing, set up persistence and access data from root or other users. There is stuff like kerberos tokens for admins, everyting secret in /etc like ldap passwords, private keys or ability to change read-only code to setup a backdoor. You can tap the admin if he uses t…

I'm honestly surprised that people still bother with multi-user access control. Defense in depth only works if the defenses are actually manned, and it's been pretty clear that nobody's been taking linux local escalation seriously for a very long time. Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.

Shared hosting is high trust? You are basically one stolen credit card and 5 minutes away from giving strangers SSH access to a host with lot's of customers that often process sensitive data.

Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you.

Lot's of Hadoop/HPC clusters or university desktops depend on this stuff.

With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it.

On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster.

Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root.

It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#69

Post by SwellJoe »

drewcrawford wrote: post #43
gizmo686 wrote: post #27

Earlier quoted context omitted.

GPLv2, section 6: "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. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

"In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it."

This is a trolling technique known as derailing. It seems to have worked a little since most of the replies are about "free speech", which isn't what this conversation is about.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#70

Post by simcop2387 »

SwellJoe wrote: post #64
simcop2387 wrote: post #58

I've got a question about this whole GPL enforcement issue. Scenario: I'm a VPS company, I provide my customers with kernels compiled with GRSec. I provide a number of modules for different protocols, nftables, etc. with the custom kernels i've built for the VMs. Under the GPL I have to provide the patched source of all those modules (and kernel If I provide that image too) to my customer. Question: With GRSec's repo…

That's a big part of the implication of this post, I think. Grsecurity heavily markets itself to the multi-tenant hosting industry. Thus, your scenario is a big part of their customer base. So, if these allegations are true, then not only is grsecurity violating the GPL, they're demanding their customers violate the GPL, too.

That's what I thought was going on from the discussion. Glad to see that it's not just me reading it that way. I'd think then that if GRSec is doing it, and intending to use it that way (I am not a lawyer) then it would appear to me that the assertion that they're violating the GPL since they're adding another restriction on distribution.
Post reply on HN