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

Grsecurity Developer Spender's Feelings on the State of Linux Security

grsecurity.net

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#61

Post by grandinj »

vezzy-fnord wrote: post #17

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow co…

Those are all user space level mitigations so you don't need the kernel to implement them. So you are barking at the wrong group.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#62

Post by aidenn0 »

hiphopyo wrote: post #54
_yy wrote: post #29

Earlier quoted context omitted.

Grsecurity's approach is superior to OpenBSD's, but both are acceptable. FreeBSD is actually behind Linux - it lacks an effective access control framework and did not have ASLR until the latest release. At least they're working on it (TrustedBSD, Capsicum).

Some interesting insights on Grsecurity's approach by OpenBSD's Nick Holland in the comments section: https://www.digitalocean.com/community/tutorials/an-introduc...

Substitute "Untrusted user" for "possibly buggy server code" and you will see why Grsecurity's approach can have value in single-user systems.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#63

Post by vezzy-fnord »

grandinj wrote: post #61
vezzy-fnord wrote: post #17

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow co…

Those are all user space level mitigations so you don't need the kernel to implement them. So you are barking at the wrong group.

Separation kernels aren't, MLS likely works best with kernel cooperation (given Linux's large surface) and same with capabilities at least.

My point wasn't the specific proactive mitigations, but rather Linus' attitudes creating negative perceptions.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#64

Post by rodgerd »

grandinj wrote: post #59

There is no monolithic upstream organization. The real problem is that it's really hard work to upstream code, particularly when it touches core parts of the kernel. Look how long it took to get other invasive stuff like tickless or preempt RT. But it got done, it just took time and patience. And insulting the upstream people like this doesn't make your job any easier.

> And insulting the upstream people like this doesn't make your job any easier.

The upstream people are pretty wedded to the idea that throwing insults is a reasonable response to frustration with poor behaviour. They do not have any legs to stand on re: hurt feelings.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#65

Post by rlpb »

hannob wrote: post #24
meirelles wrote: post #13

Earlier quoted context omitted.

I used to be a security freak guy. Using the Gentoo Hardened, GRSecurity PaX/RBAC, customized ACLs, etc. IMHO is a high-quality piece of software, very polished and well-designed... I'm a Ubuntu guy today. For my small business, such level of security is too much time consuming, drawing me back. It's kinda sad.

You know, that's the problem. There is basically no reason why this is so hard. Many security features could just be enabled by default by major distributions with hardly any downside. You don't even have to look at grsecurity. Just using pie binaries to enable proper ASLR would be a start.

Ubuntu already does quite a bit: https://wiki.ubuntu.com/Security/Features

I'm not well versed enough to understand whether "Just using pie binaries to enable proper ASLR" is included, but the chart does show green against various things mentioning ASLR. It looks like specific packages are built with PIE, too.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#66

Post by nickpsecurity »

throwaway2048 wrote: post #44
taavi013 wrote: post #34

Earlier quoted context omitted.

FreeBSD supports Mandatory Access Control, implemented as part of the TrustedBSD project. It was introduced in FreeBSD 5.0. Since FreeBSD 7.2, MAC support is enabled by default. The framework is extensible; various MAC modules implement policies such as Biba and Multi-Level Security.

and how much of the system is protected by trusted bsd by default: none of it how many people ever bother to write and deploy a trustedbsd policy: (to first order approximation) nobody Defaults matter, a feature matrix checkbox is simply deceptive because the fact something isn't on (and configured) by default often means its an insane amount to work to try to enable it and/or thing are unfixably broken when you do (…

Sounds like a demand problem rather than a FreeBSD problem. I've heard the same about SELinux etc with them overly permissive by default due to user apathy. I'd say Linux is ahead of usability of these controls, even supported by vendors like Tresys. It's also ahead in terms of risky code/tools a major distribution will support vs a major BSD. So, comparisons are a moving target.

Fortunately, the best security approaches (HW-centric) are portable to both w/ FreeBSD getting most prototypes. You can already run capability-secure FreeBSD via Cambridge CHERI project. Criswell's people are doing lots of stuff with FreeBSD and maybe Linux:

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

http://sva.cs.illinois.edu/pubs.html

Examples for Linux include these:

http://scholar.lib.vt.edu/theses/available/etd-10112006-2048...

https://web.archive.org/web/20120509155852/http://archives.e...

https://docs.google.com/file/d/0B1i_Zf52vJctMTA4YTI1MmUtNzdj...

That doesn't even include software-related techniques like microkernels, low TCB software, safe low-level languages, and automatic compiler transformations for security that neither are adopting. They're both low-medium assurance by my standards due to cultural refusal to apply what's proven to work. So, I already have predictions about tech-transfer of papers above to Linux/FreeBSD use at large. You can probably guess how optimistic I am. ;)

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#67

Post by nickpsecurity »

jpgvm wrote: post #18
vezzy-fnord wrote: post #17

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow co…

I wouldn't be so harsh. Linus thinks and works in the here and now. He is neither interested in the theoretical or bothered by what theoretical people have to say about him. He ships code that works and works well and generally speaking has a good security track record compared to many userspace systems (Adobe Flash anyone?). At the time he was against microkernels it would be fair to say monolithic kernels did defin…

The first systems to be designed for robustness (and have it in practice) were opposite of Linus's approach to doing things. There's some similarities on occasion, which mainly shows talent learned through trial and error. The proven principles for highly reliable and secure OS's aren't applied, though. This is intentional despite massive evidence to the contrary of his position.

Meanwhile, systems like THE (Dijkstra), Burroughs B5500, IBM System/38, GEMSOS (Schell), RC4000 (Hansen), MULTICS, KeyKOS (Bomberger et al), and VAX VMM Security Kernel (Karger/Lipner) showed how to design and implement systems with ultra-high reliability and/or security. These lessons were mostly ignored time and time again even when they could be applied. User-mode drivers and languages with pointer/buffer/stack protection would have by themselves prevented ridiculous amounts of problems. I heard that, after around 2-3 decades, the UNIX crowd is adding some user-mode drivers. See the problem?

Note: Far as lightweight systems & adaptivity, you should see the work of Brinch Hansen, Niklaus Wirth, and Andy Tannenbaum. They applied safe, modular techniques on systems with less resources than today's. UNIX and Linus resist for both personal preference and inertia, not valid technical objections.

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#68

Post by nickpsecurity »

emidln wrote: post #56
throwaway2048 wrote: post #44

Earlier quoted context omitted.

and how much of the system is protected by trusted bsd by default: none of it how many people ever bother to write and deploy a trustedbsd policy: (to first order approximation) nobody Defaults matter, a feature matrix checkbox is simply deceptive because the fact something isn't on (and configured) by default often means its an insane amount to work to try to enable it and/or thing are unfixably broken when you do (…

The TrustedBSD features are used by appliance vendors who base their product on FreeBSD. Applicances have very narrow profiles of acceptable use and thus it's actually sane to develop policies for them.

That's true. It goes back further than TrustedBSD: Secure Computing Corporation invented Type Enforcement, put it in a high assurance system (LOCK), put it into a BSD-OS for a firewall (Sidewinder firewall), and helped create Flask architecture for integration of type enforcement into vanilla OS's. Flask was ported to Linux in SELinux project. That got enough acceptance that TrustedBSD project was started to do same for FreeBSD. So, full circle back the the OS the tech was first fielded on.

LOCK System http://www.cyberdefenseagency.com/publications/LOCK-An_Histo...

Sidewinder firewall http://www.ittoday.info/AIMS/DSM/83-10-35.pdf

Flask project/architecture https://www.cs.utah.edu/flux/fluke/html/flask.html

Nonetheless, the old stuff (esp LOCK & LOCK/ix) are still stronger in security architecture and design despite all these years. Good design is timeless I guess. :)

Note: Cambridge's CHERI project and CheriBSD are the cutting-edge for FreeBSD security as they do capability-security from hardware up with FreeBSD already ported. Also supports Capsicum, Flask, and separation kernels if one wanted. True integration of each major branch of INFOSEC. :)

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#69

Post by nickpsecurity »

infinity0 wrote: post #31
armitron wrote: post #23

Earlier quoted context omitted.

No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is…

> Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours Do you have some details on this? I did not realise the situation was so bad.

I'm not sure objectively what the current state is. However, it's a little known fact that Linux kernel specifically (due to fame) benefits from tons of academic work on bug hunting tools. Every time they run a new one, they find all kinds of problems that are preventable with a safer language or sound architecture. Many of them would've been contained in a microkernel architecture rather than have full access to memory.

So, one could say it's pretty bad even if the "many eyes" and code audits are finding/fixing a ton. Simply too many to justify if their process is any good. An recent example I found was the Saturn project throwing an automated tool at it and finding 100+ real bugs in one go.

http://saturn.stanford.edu/pages/papersindex.html

Re: Grsecurity Developer Spender's Feelings on the State of Linux Security

#70

Post by nickpsecurity »

grandinj wrote: post #61
vezzy-fnord wrote: post #17

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow co…

Those are all user space level mitigations so you don't need the kernel to implement them. So you are barking at the wrong group.

Those might be but microkernels, safe languages, interface correctness (pre/post-condition checks), and safe coordination schemes aren't: built from kernel up and proven since 70-80's to prevent/contain many issues that affect C-based monoliths like Linux. That they actively argue against using them despite decades of evidence they work says plenty about them. That they also advocate and use methods that haven't worked for decades in terms of predictability/reliability/security is final nail on the coffin.

People should keep barking given how much depends on the project now. Plus support alternatives that take better approaches to architecture like old EROS, MINIX 3 (reliability), or GenodeOS (security/reliability). Safe native approaches like security-enhanced Oberon System or JX Operating System would also kick butt. Each achieved certain robustness properties in mere years with small teams due to good design.

UNIX and Linux took decades to get usable, still give hackers MB of opportunities for kernel attacks, and still crash my systems on occasion. Meme: "Failure to learn the lessons of the past and apply them."

Post reply on HN