Grsecurity Blog

IMHO it can be done, using UNIX-based operating systems and standard open source software, if the infrastructure designer takes security seriously and is committed and knowledgeable.

It's NOT the system administrator's work to secure the network. The ISP/minor IT company should have a security engineer to overview the network, although some sys-admins are extremely skilled when it comes to security.

There are so many security layers that can be implemented on a Linux/BSD server that makes the machine virtually un-hackable and IF anyone enters, all bells and whistles could start cheering.

Examples: GRsecurity[1], IPTables[2], Snort[3], chroots (or jails), VPNs, malware scanners (clamav, spamassassin), encryption and what-not.

To me securing linux desktops, especially simple ones (e.g. window manager + basic programs... almost like thin clients) is easy. Securing Windows XP/7/8/etc is extremely tricky BUT can be done.

Once you do all that, I'm 100% that you're going to be one hell of a target for anyone. And you really don't trust your team you can always hire people to test your network's security and improve it.

The most important thing though is having a strict general user policy: What users can and can not do must be crystal clear with no exception. When a 'tiger team' finds a secure network, they usually target the people not the infrastructure.

[1] GRsecurity: https://grsecurity.net/

[2] http://www.netfilter.org/projects/iptables/

[3] https://www.snort.org/

It's funny. I was just learning about RuneWatch, which is how the Runescape community attempts to democratize and distribute the problem of dealing with scammers.

The evolution was basically that it started the way CVEs work. You could submit a report and there wasn't really any verification. Of course, this was abused - far worse than the CVE system, naturally, but the same sort of problem.

Now they require a lot of evidence and things are much much better and abuse is far more difficult.

It seems sort of obvious. If this is a vulnerability, prove it.

It almost feels like a CVE should have a "practical" tag. Like:

1. Is this theoretically exploitable?

2. Is this practically exploitable?

3. Is this proven exploitable?

This should be a massive contributor to the score. It also means that a score can be raised by having the sec researcher demonstrate an exploit - so disagreements can be resolved very easily.

Related, here's a post from Spender on the topic (since the "CVE bad" situation is nothing new)

https://grsecurity.net/reports_of_cves_death_greatly_exaggerated

Edit:

I replied too soon and misunderstood the core of Peren's argument.

His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes.

At issue is this agreement:

https://grsecurity.net/agree/agreement.php

This clearly represents additional conditions imposed on the software. Seems like a grey area as to whether those conditions at enough to violate the GPL under which the Linux kernel is licensed.

Original comment:

I don't buy it.

Grsecurity isn't distributed as a derivative work of the Linux kernel.

Just because it's useless without the kernel doesn't make it a derivative work. By that logic, Nvidia's closed source driver would qualify as a derivative work and fall under the GPL.

> This is likely to be easy to exploit for privilege escalation, except on systems with SMAP or UDEREF

Another reminder why everyone should be using https://grsecurity.net which provides these mitigations to the Linux kernel via patches. GRSecurity has had SMAP aka KERNEXEC for a long time as well as UDEREF https://grsecurity.net/~spender/uderef.txt

If you keep any sensitive data on a Linux server you should seriously consider grsec.

Even last week there was an ASLR bypass posted on OSS-security which of-course grsec already protected you against http://seclists.org/oss-sec/2014/q4/908

There is a lot of drama around the fact Linux core devs don't adopt these patches by default. But regardless Linux is pretty insecure by default and grsec makes privesc via various classes of exploits significantly harder.

> Similarly Linux has "Linus decentralisation": there's an elaborate decentralised version control system, but nonetheless Linus has effective final veto in practice. And Etherum has "Vitalik decentralisation": disasters such as the DAO can be reversed by code changes, because even if the blockchain is immutable the code required to interpret it isn't.

There is nothing but "sheep mentality" preventing most people from (hard) forking.

Don't like what Ethereum did with the DAO incident? Don't patch. See https://ethereumclassic.github.io/

Don't like what Linus did (not) merge? Fork the project, and patch it like you want. See https://grsecurity.net/features.php

Linux as a service is most of Redhat and Canonical's business models.

grsecurity does this from a security angle specifically - in fact they're boasting about it on their homepage right now (fair enough!)

>Are Your Products Drowning in Linux Kernel CVE Noise?

>We know your products can't be updated every week based off unverified CVE information. Address true risk by protecting against entire classes of vulnerabilites and exploitation techniques. Our Pro Support ensures you make the most of attack surface reduction and our proactive defense in your products.

https://grsecurity.net/