Security part 2

On the middle day of the 2015 Kernel Summit, when mostly technical topics were considered, Kees Cook urged kernel developers to take security more seriously. The invitation-only group held a followup discussion one day later regarding what should actually be done to improve the kernel's security. It seems there is a possibility that we will see more security-related features going into the kernel in the near future.

Ted Ts'o started by asking the group whether they were willing to add "painful security stuff" now. Kees suggested starting by taking another look at the PaX and grsecurity patch sets. There are a lot of things that can be done, he said; it's mostly a matter of finding people to work on them. He is one of those people, but he's only one person and the problem is larger than that.

James Bottomley asked if there was one security-related technology that the kernel absolutely should support. Kees answered that we should never execute user-space code in kernel mode.

Linus said that it would indeed be useful for somebody to go through the PaX and grsecurity patches. But that code needs to be looked at carefully. For example, they have implemented protections against executing user-space code, but (according to Linus) they have done so badly. Now hardware offers that protection and we can use it; if we had accepted their code, we would be in a deep well we couldn't dig our way out of. He is glad he refused to take it.

Other parts of those patch sets include "slow, horrible code" that affects fundamental parts of the kernel. He called out in particular the fact that grsecurity adds more use of the high-memory concept, while the kernel developers are instead trying to get rid of it. That said, he allowed that there is probably useful stuff to be found there.

Kees said he would like to document the individual pieces of those patch sets, describing the class of bug addressed by each. The easiest to adopt, he thinks, would be the GCC plugin defending against integer overflows. That would bring the plugin infrastructure into the kernel process and allow developers to experiment with it.

Greg Kroah-Hartman said that the Core Infrastructure Initiative (CII) is willing to fund work improving the security of the kernel, but there is nobody out there to actually do this work. What CII won't do is fund grsecurity to go off in a corner and do its own thing (and, he noted, grsecurity isn't asking for that). The problem is that people who can do this work tend to get quickly hired to do something else.

Kees wants to start by overcoming the kernel community's cultural resistance to the addition of security technologies; he feels that some progress has been made in this area. After that, the next challenge is finding people to do the work. James asserted, though, that cultural resistance is necessary; security is a tradeoff, and we have to find the proper middle ground. So the argument will have to continue.

Ted suggested the addition of kernel-configuration options for the more intrusive security lock-down features. We just have to accept, he said, that some of these features will be painful for developers and will often be disabled on developer machines. They are more than acceptable on handsets, though. It was noted that, in enterprise settings, there is often a need for extensive diagnostic information for support purposes. Security features tend to make such information unavailable, so they can't be enabled; given a choice between security and support, many companies will choose support.

Kees said that support might be an area for some innovation. Kernel symbol information could be made available via an encrypted channel, for example, so it would be available to those who have the right key. James said that the checkpoint/restore work is an example of how things can be done. Initially it required the export of a lot of system information, but things have been closed down over time; features like the kcmp() system call allow checkpointing to be done without leaking important information. It should, he said, be possible to get debugging information out of the kernel without helping attackers.

Ted highlighted live kernel patching as an interesting tradeoff; there is little observable difference between the application of a patch and the installation of a rootkit. So live patching may never be enabled in a number of environments. Masami Hiramatsu said that the module-signing mechanism could be used to verify kernel patches.

The session ended with no clear conclusions. There does appear to have been a bit of a shift toward greater acceptance of security enhancements, but the real proof of that will come when the patches start circulating.

Index entries for this article
Kernel	Security
Security	Linux kernel
Conference	Kernel Summit/2015

---

to post comments

Security part 2

Posted Nov 5, 2015 12:11 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]

"Now hardware offers that protection and we can use it; if we had accepted their code, we would be in a deep well we couldn't dig our way out of. He is glad he refused to take it. "

Besides the obvious FUD, what Linus fails to acknowledge or remember is that a lot of security features that are now in Intel CPUs now may well have emerged thanks to PaX implementing them first... NX, SMAP/SMEP come to my mind first.

"Other parts of those patch sets include "slow, horrible code" that affects fundamental parts of the kernel."
Maybe because they try to address fundamental problems with the kernel ? And PaX/grsec puts the balance of the security trade-off on the security side vs performance ?

It has always been clear that having Linus as the final decision maker has hurt Linux security more than anything else. It is good to finally have someone trying to work inside the kernel community to tackle the problem, but Linux is now lagging years behind Windows in terms of security, and it is very sad.

Security part 2

Posted Nov 5, 2015 20:20 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (2 responses)

So, let me see if I'm getting it right... Linus is glad to have refused to take UDEREF and KERNEXEC.

IOW, he's glad that a crushing majority of users of the Linux kernel keep running insecure flavors which will blissfully dereference ops structures in userspace, then proceed to execute code in userspace. Most Linux kernel exploit PoCs I've seen mentioned on LWN over time do both.
He's glad that a crushing majority of users of the Linux kernel aren't enjoying effective defenses created many years ago, which:
* do not require any special hardware support available only on a tiny minority of recent x86_64 processors (SMAP-capable processors are very recent, SMEP is a bit older) or semi-recent ARM processors (domains, PXN, etc.);
* support more (no fewer, at least) ISAs;
* provide a _strict superset_ of the capabilities of SMAP (see posts by spender and PaXTeam at https://lwn.net/Articles/517749/ , https://lwn.net/Articles/617945/ , etc.), and IIRC, SMEP as well.
Yes, I'm aware that UDEREF, especially, has a measurable performance cost.

Oh well. We already knew that despite Kees Cook's efforts, mainline kernels will remain lacking in anti-exploitation abilities and therefore knowingly insecure for the years to come, due to lack of features which have been known for a decade, and are _far_ better battle-tested than much of the code which constantly gets thrown into the kernel :)
In the meantime, the PaX Team, spender and Emese Revfy keep working part-time adding innovative features for anti-exploitation, disabling or strongly hardening insecure features which reach mainline on a frequent basis, and leaving mainline Linux even deeper in the kindergarten, from a security standpoint.

BTW, a reminder: PaX/grsecurity contain _hundreds_ of cleanups and minor improvements which have no, or low (but positive), security impact, and have usually been there for years, because the mainline submission process is too costly (in terms of developer time) and because too few core kernel developers actually look at PaX/grsecurity, sadly.
One can easily find hunks aiming at, for instance:
* removing "static" from a dozen of variable declarations where said "static" is superfluous for the purposes of the function (the first thing the function does is reinitializing the variable, so no need to persist the value across calls), e.g. drivers/mfd/max8925-i2c.c and drivers/mfd/tps65910.c, last time I checked;
* using more C99 designated initializers in many structs (too many to list) - probably originally a consequence of RANDSTRUCT, but a readability improvement;
* adding __force_user and __force_kernel annotations for the checkers (too many to list);
* constifying some function arguments, so as to make it harder to inadvertently modify them (e.g. mm/slob.c).
These hunks are more useful to the Linux project than whitespace patches that maintainers are complaining about, and are good candidates for newcomers with a bit of programming experience. Besides the minor improvement to Linux, mainlining those patches t would unclutter the monster PaX/grsecurity patch.

Security part 2

Posted Nov 6, 2015 0:06 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

With advocacy like that every time it's mentioned, I'm glad he didn't validate their attitude by accepting their code too.

Security part 2

Posted Nov 6, 2015 7:19 UTC (Fri) by bartavelle (guest, #56596) [Link]

Yes, attitude is certainly the most important concern when it comes to Linux contributors, and Linus sets a fine example here !