KS2010: Security

By Jonathan Corbet
November 3, 2010

2010 Kernel Summit

Running a site like LWN provides a great deal of experience in making a fool of one's self in front of crowds of knowledgeable people. So perhaps it was natural that your editor, of all people, ended up running a session on security at the 2010 Kernel Summit. The purpose was to share some concerns about the security of the kernel; whether anything was achieved remains to be seen.

The background for the session was the list of 80 CVE numbers assigned to the kernel so far this year - a list which is known to be far from complete. We are currently logging more than two vulnerabilities per week, making the kernel a leading cause of the global shortage of available CVE numbers. Even if a number of these vulnerabilities are not gravely worrisome (there are many of the "might leak eight bytes of kernel stack to user space" variety), others are full root compromise holes. Events like the Stuxnet worm have made it clear that there are groups with significant resources which are interested in compromising targeted systems; perhaps it is time for us to up our game somewhat. Your editor is clearly not alone in thinking this way.

The questions your editor had for the group in particular were:

Are we happy with the state of Linux security? Or do we maybe think we should be doing better?
Assuming we want to be doing better, what should we be doing to improve the situation?
How confident are we in our web of trust? Given the number of vulnerabilities in the kernel now, it seems unlikely that anybody would need to go to the trouble of deliberately injecting new ones. Even so, it would be nice to know that we are robust against such attacks.

Linus responded to the last question first. Once upon a time, he said, most pull requests came from trees which were hosted on kernel.org. That increased his confidence: he liked having a relatively small set of source trees on a well-protected system. Now increasing numbers of requests are coming for trees on public hosting services. He does not refuse to pull from such trees, but he wanted to let it be known that he does scrutinize what he finds there more closely. So far, Linus has never received a malicious pull request - that he knows about.

Somebody asked whether people pushing trees to Linus should be required to get a kernel.org account; he thought that would not improve the situation. The main comfort from kernel.org-based trees came from their relatively small number; creating more would just make things worse. Another question had to do with whether developers should have to cryptographically sign their trees. Linus thinks it would be more pain than it is worth; the key management would be no fun at all. And, he says, requiring signatures would just push the problem down one level. In the end, you need to know who to trust.

A number of developers took the position that security holes were really just a review problem. Ted Ts'o agreed, but also cautioned that a look at the results of the Underhanded C Contest were worth a look. Malicious code can look awfully innocent with enough effort.

Greg Kroah-Hartman said that security bugs are just bugs, and we've been fixing them as quickly as we find them. Linus had some strong words for "security" companies which pay people to find bugs and keep them to themselves. This activity may somehow attract customers, but it sure doesn't improve anybody's security.

There were questions about adding better defenses against specific attack patterns. Some of that has been done; many core VFS system calls have parameter checking at the VFS layer, making it hard to introduce vulnerabilities further down. Some work has just been done (after some new vulnerabilities were reported) to harden the handling of iovecs in network protocol implementations. Certainly there is more that could be done in this area. But, as Linus pointed out, many of the problems tend to be in ioctl() implementations, and there's little to be done about those at the higher levels.

Mike Rubin asked what the community's commitment to security is. He is having a hard time knowing which parts of the kernel he can rely on to be minimally secure. Linus said that the best answer is to ask how many people are using any specific bit of code. Modules with more users have had more testing and developer attention, they tend to be more secure.

Tony Luck asked about whether people are testing the kernel using fuzzing tools. Some attackers certainly are, it seems, but it's not clear that kernel developers are doing the same. Among other things, one would think that the recent 64-bit system call vulnerability, which sat undiscovered (by the good guys) for two years, should have been caught by any serious amount of fuzz testing.

By the end of the session, it seemed clear that many of the developers in the room remained mostly unconcerned about the kernel's security record. To the extent that they are concerned, they don't see what can be done beyond continuing to look at code and fix bugs as quickly as possible.

Next: Scheduler issues.

Index entries for this article
Kernel	Security

to post comments

KS2010: Security

Posted Nov 3, 2010 23:08 UTC (Wed) by vomlehn (guest, #45588) [Link] (1 responses)

One hopes the Editor's perception that "many of the developers in the room remained mostly unconcerned about the kernel's security record" is wrong. Linux has just about vanquished any significant competition in the embedded market and the rewards for pwning those systems can be rich, indeed.

KS2010: Security

Posted Nov 3, 2010 23:43 UTC (Wed) by dlang (guest, #313) [Link]

you are reading this as "developers don't worry about security" when I read it as "developers think they are doing a decent job with security and don't see a pressing reason to make changes"

KS2010: Security

Posted Nov 4, 2010 9:35 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (27 responses)

I'm employed as a programmer in user-space, but I don't know _that_ much about security, and I'd like to learn further, for both user-space and kernel-space (since kernels are supposed to protect programs against each other, and protect themselves against potentially malicious user-space).
So it happened that I recently looked through the grsecurity patch, after seeing "spender", i.e. one of its developers, mentioning it multiple times in LWN comments.

Needless to say, most changes in the grsecurity patch go over my head, but some hunks looked simple to _me_ at least. Namely, the hunks related to:
* making "const" dozens of struct instances, e.g. *_ops structs: IIUC, on some architectures, they can end up pushed to a read-only area protected by the MMU, so that attempts to rewrite it yield some low-level exception, hopefully ending up in the offending program being killed;
* making "const" more struct fields - compilers complain about direct attempts to change the values within the kernel itself, so it can be an early thinko/typo catcher;
* adding more "__user" annotations - IIUC, it can help human programmers and static code checkers to know that the parameters marked "__user" contain input from, or output to, user space;
* changing some variables from "int" to "unsigned int" - IIUC, this can be related to integer overflows ?
* "asm volatile" instead of just "asm" - looks like "volatile" can prevent the compiler from meddling up with the assembly fed to it, not sure why it should do that.

Searching about "grsecurity const" led me to http://www.grsecurity.net/~spender/more_const_fixes.diff , for an older version of the kernel, and to another discussion on LWN, http://lwn.net/Articles/346299/ , more than one year ago. This discussion precisely mentions instances of one struct type made const, and spender pointing to more structs that could be made const.

So in the end, I'd like to ask: what are the downsides to making those *_ops structs const, or adding more annotations, in mainline kernels ?
I say this in a respectful way: I'm not able to imagine by myself reasons why e.g. "const-ified" *_ops structs are not part of the mainline kernels.

Thanks in advance for enlightening me ;)

KS2010: Security

Posted Nov 4, 2010 11:04 UTC (Thu) by mingo (subscriber, #31122) [Link] (26 responses)

There are no downsides at all to such patches - if something is truly immutable we want it const, and we want to propagate that information through all call sites. It improves security and it improves code readability as well.

It would be nice to push such grsecurity patches upstream. If you'd like to help out splitting things up and pushing them upstream, it would be a very useful effort. (Maybe the grsecurity author(s) will help you out with that as well.)

I'd suggest for you to start with the simplest, smallest and least controversial changes - the best way to learn the ropes.

KS2010: Security

Posted Nov 4, 2010 14:47 UTC (Thu) by kees (subscriber, #27264) [Link] (24 responses)

Grsec+PaX includes a change in how read-only memory operates, and without that change, the const stuff isn't as strong. For example, in mainline the readonly regions in modules aren't enforced at all.

KS2010: Security

Posted Nov 4, 2010 19:07 UTC (Thu) by dlang (guest, #313) [Link] (23 responses)

even so, I don't think that the kernel developers would object to patches that cleaned things up and made the read-only status of things explicit.

Doing this may not help security much without the change you mention below, but it would reduce the size of the GRsec patchset, which would then mean that those people would not have to maintain this sort of thing as a external patch.

Then with the read-only status clearly defined for things, the kernel developers may be open to a configurable option that would change how read-only memory works, if the performance impact could be clearly documented (and under some conditions, making things read-only may result in performance increases, if it means that the system can allow multiple copies of the data to exist in CPU caches without having to worry about keeping them in sync because they are known to never change)

the key thing is to not pitch this as 'this is a critical security fix, take it immediatly', but instead pitch it as 'This is a cleanup to make otherwise undocumented assumptions about how variables are used explicit, improving long-term maintainability It has the potential to have a minor performance improvement and security gain, but only if the read-only status gets enforced.'

this changes the reason for accepting the patches into something that they can see a direct benifit for.

KS2010: Security

Posted Nov 4, 2010 19:24 UTC (Thu) by mingo (subscriber, #31122) [Link] (21 responses)

Doing this may not help security much without the change you mention below, but it would reduce the size of the GRsec patchset, which would then mean that those people would not have to maintain this sort of thing as a external patch.

Btw., this would be the right approach even if the authors of a security patch wouldn't want any of this to be upstream.

Some authors may be fine with having a product which can always be claimed to be 'safer than upstream' - because it's a security fork. It also gives them a constant stream of exploits that hit mainline but are averted via a security patch.

So security enhancements generally have different marketing and economic constraints from other kernel enhancements, and merging things upstream can be undesirable/counterproductive to any 'security circus' aspect.

I have no way to tell whether that's the case in the grsecurity case though - but it's something to consider. If they are helping such efforts then all the better - but unlike other kernel forks it's not necessarily in their own best interest.

Same goes for the Coverity static checker project as well. That too is a project that would essentially die if we had a static checker in the upstream kernel, which would be tightly integrated with the kernel build (like Sparse) and which could thus avoid bugs in their infancy, right when they are introduced.

Security is a weird field.

KS2010: Security

Posted Nov 4, 2010 22:18 UTC (Thu) by spender (guest, #23067) [Link] (17 responses)

Please don't compare us to Coverity. From every angle, this is just an incredibly poor argument (and I'm not even covering all the ways in this post). BTW, if I were as pretend-concerned as you with contrived conspiracies, I'd apply your academic analysis to your own exec-shield work.

Our source is open for anyone to use. We have no "marketing and economic constraints." And sorry, but the only thing 'circus'-like is upstream's approach to security.

You were already linked by the parent poster to the initial split-out const patches I made up over a year ago. What happened after that is quite typical of upstream's handling of security; it's treated more as a nuisance, something to brush out of the way by means of token gifts of minor improvements. There's no overarching goal or dedication to completeness; the recent thread on /proc/kallsyms that you participated in is a perfect example of this cargo-cult security. So someone will merge a few small patches that are ultimately useless by themselves, and then the idea will be dropped again until someone like the parent poster points out the stupidity of not having merged all of them.

We'll also ignore the fact that all of the const patches were already split up and sent to LKML multiple times, but that only a tiny fraction of them were merged.

So don't regurgitate this inapplicable 'security circus' crap from Linus and act as if it's profound; it's not. There's a simple truth here: upstream had more than enough opportunity over several years to adopt the changes, the work having already been done multiple times by multiple people. Nobody's holding on to any code or trying to prevent it from being merged. If upstream wanted it merged all they had to do was accept the submitted patches.
Look and see for yourself what happened in the most recent attempt:
http://lkml.org/lkml/2009/12/4/346
I think that entire effort only reduced our patch size by about 50kb (out of what is nearing 2MB).

As far as where our own interests lie, it's in reducing the amount of time required for the patches. The time spent maintaining the const patches on our end is next to nothing (just some trivial rejects from nearby changes). The time and frustration involved in getting them all merged upstream is ridiculous. Even when some do get merged, more get added in in the following release that need to be fixed because there's no enforced upstream policy on the const-ness of various structures. So what happens? Upstream doesn't bother fixing them. Emese, the author of the set submitted to LKML, now maintains them just for us as there's no red-tape and no hassle.

Your backhanded derision in the form of a disingenuous question, posed as a faux-naive outside observer, belies the fact that if upstream is looking for someone to blame as explanation for why the changes haven't been merged, it needs only to look in the mirror.

-Brad

KS2010: Security

Posted Nov 5, 2010 9:00 UTC (Fri) by mingo (subscriber, #31122) [Link] (16 responses)

I'd apply your academic analysis to your own exec-shield work.

Actually, FYI, a fair portion of exec-shield is upstream so your comparison fails right there.

Secondly, the few bits that are not upstream are the ones that were rejected explicitly by the VM maintainers. I have submitted them multiple times and early on. There was even a fine LWN article about it.

Look and see for yourself what happened in the most recent attempt: http://lkml.org/lkml/2009/12/4/346

Erm, have you read the fine lkml discussion you have linked to?

I did, and it showed me a lot of acks from maintainers and some bugreports even.

In fact a fair amount of constification patches went upstream after the time you submitted similar work:

 756e64a0b106: net: constify some ppp/pptp structs
 2e7a091833f0: kconfig: constify file name
 52dfb8ac0ef4: ceph: constify dentry_operations
 54e5bc020ce1: x86, olpc: Constify an olpc_ofw() arg
 f6db25a87643: squashfs: constify xattr handlers
 b7bb0a12913a: gfs: constify xattr_handler
 537d81ca7c53: ocfs: constify xattr_handler
 365f0cb9d2d5: jffs2: constify xattr_handler
 46e58764f0c5: xfs: constify xattr_handler
 94d09a98cdb1: reiserfs: constify xattr_handler
 11e27528076e: ext4: constify xattr_handler
 d1f21049f918: ext3: constify xattr handlers
 749c72efa4bd: ext2: constify xattr_handler
 f01cbd3f8148: btrfs: constify xattr_handler
 5bac942db3d2: SH: constify multiple DMA related objects and references to them
 52cf25d0ab7f: Driver core: Constify struct sysfs_ops in struct kobj_type
 9cd43611ccfb: kobject: Constify struct kset_uevent_ops
 42747d712de5: [WATCHDOG] watchdog_info constify
 8838d2560a8c: Staging: rt2870sta: constify RTUSBMultiWrite(), RTUSBFirmwareWrite()
 a4c1a148a0c4: OMAP: DSS2: OMAPFB: Constify some function parameters
 af930d646251: Input: gamecon - constify some of the setup structures
 e87a344d0eef: Input: wacom - constify product features data
 739674fb7feb: netfilter: xtables: constify args in compat copying functions
 3b9cfc0a99f8: x86, mtrr: Constify struct mtrr_ops
 5833929cc2ad: net: constify MIB name tables
 45d5d805988f: iwlwifi: Constify struct iwl_ops
 7d4e9d0962cd: drbd: Constify struct file_operations
 f65380c07b64: resource: constify arg to resource_size() and  resource_type()
 28dfef8febe4: const: constify remaining pipe_buf_operations
 9905a43b2d56: backlight: Constify struct backlight_ops
 7707e61c7099: ctype: constify read-only _ctype string
 471452104b85: const: constify remaining dev_pm_ops
 3428838d8e88: page-types: constify read only arrays
 1cceefd3a28e: tty: const: constify remaining tty_operations
 b62d99b5028b: PCMCIA: soc_common: constify soc_pcmcia_socket ops member
 a9966b580a3e: ieee802154: constify struct net_device in some operations

So this looks like good stuff, and it's being done - you got the acks - so why didn't you push your bits upstream? Have you asked akpm to include it in -mm, or have you prepared a tree yourself and sent a pull request to Linus? It's been a year since you submitted those patches - what are you waiting for?

Really, are you interested in keeping grsecurity forked? In your long reply i have not seen a single offer from you to make a serious push to merge grsecurity upstream. Instead you complain about the upstream process:

What happened after that is quite typical of upstream's handling of security; it's treated more as a nuisance, something to brush out of the way by means of token gifts of minor improvements.

The thing is, i have the exact opposite experience - security work is handled seriously and bugs are handled swiftly. The upstream kernel is aflush with security work. Patches are being welcome - check the very link you provided!

Instead of working with us you are hurling such insults at Linus:

So don't regurgitate this inapplicable 'security circus' crap from Linus and act as if it's profound; it's not.

Have you considered the theoretical possibility that Linus honestly believes that the 'security circus' stock full of parasitic poseurs exists?

KS2010: Security

Posted Nov 5, 2010 9:37 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

quote: Have you considered the theoretical possibility that Linus honestly believes that the 'security circus' stock full of parasitic poseurs exists?

as someone who makes a living in the security field, I can assure you that there is plenty of security circus and the field has a huge number of parasitic poseurs in it. anyone who doesn't believe this, please explain current airport security in real cost/risk terms.

there are also a lot of us who are just trying to keep ahead of the bad guys and explain the problems to management, unfortunantly we have a hard task to do and it isn't nearly as appealing as the marketing security circus to management who doesn't understand the technology at all

KS2010: Security

Posted Nov 5, 2010 10:26 UTC (Fri) by mingo (subscriber, #31122) [Link] (2 responses)

there are also a lot of us who are just trying to keep ahead of the bad guys and explain the problems to management

Yeah. And i think you can consider Linus one of your best allies in that quest really. (He just refuses to play the circus - and IMHO he has rather good and consistent arguments for that.)

KS2010: Security

Posted Nov 5, 2010 11:24 UTC (Fri) by ortalo (guest, #4654) [Link] (1 responses)

Héhé, I hope he has seen that nice recommendation!

More seriously, that "circus" issue is really an annoying one and very deeply rooted in the field, I second that. Furthermore, from my own experience (subjective of course), I have to admit that most people with some responsibility (the "bosses") tend to be much more attentive to legal or marketing reasons than to practical/technical ones, from the security-oriented point of view. I am sure even Linus (or myself) can also feel this natural bias. This seems to me the fundamental reason why such theatral activity can exist and persist. And while the circus plays and attract attention in the forefront, technical problems and vulnerabilities bury themselves deeply in the code where they can stay for years and users opportunistically take advantage of the low light to write their passwords on a sheet of paper they "hide" in their wallet.
I have yet to fully understand the reasons for the long lasting existence of all this useless drama. But to me, it seems that this security circus is indeed a reality that we will need to cope with for a long time (from an historical persepctive, it may be that it fades away behind actual action in war times, but that's not a good reason to drop general pacifism... ;-).

So that refusal from the top-level kernel maintainer to play in the security circus sounds as an overall good news to me; but then, how does he want to play the security game (to get practical and continuous improvements to the overall security level of the kernel)?

Note: I certainly have a lot of ideas to propose on this topic: I've just deleted a lot of lines in this comment (the most interesting ones were probably associated to applying Coccinelle to identify missing "consts").
However, the very only comment I want to make is: then, how does Linus want to improve security management of the kernel (assuming he thinks improvements are possible)?

KS2010: Security

Posted Nov 5, 2010 15:09 UTC (Fri) by dlang (guest, #313) [Link]

the key thing her eis that the kernel developers are fixing security bugs, they are fixing them just like all other bugs, as fast as they can find them and figure them out.

and they think that they are doing a pretty good job, and don't see a reason to make significant changes.

KS2010: Security

Posted Nov 5, 2010 12:51 UTC (Fri) by spender (guest, #23067) [Link] (2 responses)

Can you elaborate on how TSA and the airline industry prevent the Linux kernel developers from developing even rudimentary security measures?

-Brad

KS2010: Security

Posted Nov 5, 2010 14:10 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

I feel that this rhetorical question may sway the discussion, not good ;-)

KS2010: Security

Posted Nov 5, 2010 15:20 UTC (Fri) by spender (guest, #23067) [Link]

Which is the point. The entire 'security circus' business is an excuse to avoid the real issues here. Phrased differently, what does 'security circus' have to do with upstream improving the security of their own kernel?

The answer is: "nothing." So why is it brought up so much when it's completely irrelevant to any kind of discussion we're having here?

I can think of a million better questions, like "what is Linux doing to attract security talent for mainline work instead of pushing away potential contributors?" or "Linux is used on millions of systems; why isn't there a single person employed full-time to improve upstream kernel security?" or "How can we move away from the find bug/patch bug mindset/approach to security?"

But it says a lot about an individual and their view toward security when the most useful thing they can muster is some regurgitated crap about "security circus" as if they're saying something insightful or intelligent.

-Brad

KS2010: Security

Posted Nov 5, 2010 12:24 UTC (Fri) by spender (guest, #23067) [Link] (8 responses)

I think you're horribly confused if you feel that upstream's security is somehow a responsibility of mine.

Let me make this clear: upstream collectively doesn't even have the common sense to acknowledge the existence of security bugs. The 'security circus' is a nice red herring to divert the blame for why Linux security is so atrocious. Maybe seven years ago you could complain about the one or two companies that embargoed vulns to make a name for themselves, but even then it would have been a poor excuse (again that anyone but upstream itself is somehow responsible for upstream's security). I hate to tell you, but those companies are long gone, and there's now nobody in the industry embargoing bugs for fame or anything else you attribute to this 'security circus.' Only notable exception being ITL with the stack/heap gap issue, though you were already notified about that in a 2005 presentation and did nothing about it; so sorry, you lose the ability to complain. That neither Linus nor anyone else has noticed this just illustrates how out of touch with the real world you all are. All you have now is people *volunteering* to try to fix things, and upstream acting like a bunch of idiots. Do you want a medal or something because upstream accepts submitted patches for trivial vulnerabilities found by volunteers? That's hardly a measure of success.

Complain about the 'security circus' all you want, this mythical boogieman that somehow magically prevents you from making any security improvements of your own, but until upstream takes a serious approach to security, I'm afraid the joke is on you. Distros taking a month to release updated kernels for vulnerabilities that only require reusing some of my enlightenment code to exploit is ridiculous. Time and again you have vulnerabilities capable of weaponized public exploits on day one; how many more years will it take for upstream to realize this is a serious problem worthy of actual attention?

Until then, keep up your "de-pessimizing" strategy to security: https://patchwork.kernel.org/patch/276921/

BTW, if I wanted to check for the existence of parasitic security poseurs, I'd probably look for more posts from this guy: http://lkml.org/lkml/2010/11/4/335

-Brad

KS2010: Security

Posted Nov 5, 2010 13:59 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (7 responses)

* On the one hand, to the taste of a number of security researchers (represented here by one member both significant and vocal ;-) ), mainline (Linus' tree) isn't doing enough for security. On the other hand, to the taste of top kernel devs (represented by at least another significant member here), the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity. And the status quo is not good for users.

* It's sad that several hundreds low-controversy one-/few-liners from the huge grsecurity patch, which can be imported to mainline more easily than lots of other patches, without demonstrable performance or size penalty, remains developed outside of mainline.
Dan Rosenberg gets dozens of small patches, mostly fixes for information leaks, committed in mainline and backported to stable. So mainline does pay at least _some_ attention to security, and does prefer smaller patches, too.

* Brad says that new non-const struct instances are added all the time to mainline. And this is despite checkpatch.pl, which is supposed to be applied by authors before submitting patches, checking more than 30 _ops types for constness. But again, mainline certainly isn't against one-liner-per-type improvements to checkpatch.pl ;-)
And, in case somebody forgets to use checkpatch.pl (we programmers are just humans !), is there a gateway that passes each commit that enters mainline through checkpatch.pl ? Or a gateway integrated with the linux-next infrastructure, so that patches other than staging get hopefully fixed in the individual trees before they enter mainline ?

* The RO/NX patch for modules, one of the most recent incarnations of which seems to be http://lwn.net/Articles/372256/ / http://thread.gmane.org/gmane.linux.kernel.lsm/10347 , seems to have vanished: in the discussion thread, Kees Cook posts that he cannot find the patch in any tree he looked at... but there's a tip-bot notice for that patch ?

* Multiple patchsets (e.g. -mmotm and -ck) are provided, between other formats, as broken-out series, for easier consumption and review. I've looked for a broken-out series corresponding to grsecurity, but I haven't been able to find it. I haven't found the scripts for regenerating e.g. the _ops constification either - it's not that it's really hard to re-create them, but it's stupid to duplicate such work. Do I fail at reading Web pages or using a search engine ?

KS2010: Security

Posted Nov 5, 2010 15:07 UTC (Fri) by spender (guest, #23067) [Link] (3 responses)

> * On the one hand, to the taste of a number of security researchers (represented here by one member both significant and vocal ;-) ), mainline (Linus' tree) isn't doing enough for security. On the other hand, to the taste of top kernel devs (represented by at least another significant member here), the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity. And the status quo is not good for users.

Indeed, the status quo is not good for users. But I don't see how that is the problem of anyone but upstream. I only feel a responsibility toward my own users. Upstream is a lost cause for security, as far as I'm concerned. It's a waste of my time to deal with them and their narrow-minded view of security. If in the future they grow up and deal with security properly, then we'll re-evaluate working with them. As it stands, they continue to have the mentality that security just involves fixing bugs (which fits with the 'a bug is a bug' tautological stupidity).

And as I said earlier, when you go looking for "successes," it's mostly just them accepting trivial one-line patches for security issues found en masse via grep. What happens is quite different when a patch doesn't accompany the vulnerability report. So I reject this entire business of "the grsecurity folks aren't doing much to reduce the gap between mainline and grsecurity" -- it's not our job or what we want to be spending our time on.

> * It's sad that several hundreds low-controversy one-/few-liners from the huge grsecurity patch, which can be imported to mainline more easily than lots of other patches, without demonstrable performance or size penalty, remains developed outside of mainline.
> Dan Rosenberg gets dozens of small patches, mostly fixes for information leaks, committed in mainline and backported to stable. So mainline does pay at least _some_ attention to security, and does prefer smaller patches, too.

They prefer smaller patches, except when they don't. Look at the const patchset. First it wasn't split up enough, they complained, then somehow even though it was split up exactly as they asked, they complained that it was now split up too much. Sorry, but I view it as a failure of Linux if security improvements are dependent upon benevolent individuals with unlimited amounts of time to waste and an iron will.

-Brad

KS2010: Security

Posted Nov 5, 2010 15:16 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

thank you for the clear statement.

if you don't feel and responsibility for anyone but your users and have no intent to try and push the fixes upstream,then your tree just became pretty irrelavent to linux security for anyone except for your users.

some people may choose to try and parse things apart to get them upstream, but very few people will want to try, so the security fixes that get into the kernel will be developed independantly (even though you will make a lot of noise each time someone recreates your work)

if you don't care about normal linux users, only your users, please quiet down about upstreams's policies, you've just said you don't care about anyone that uses it, so why should you care about it's policies?

KS2010: Security

Posted Nov 5, 2010 15:35 UTC (Fri) by spender (guest, #23067) [Link]

Because upstream's policies affect me and my users? I don't really need to explain the hierarchy and why "upstream" is called "upstream", do I?

-Brad

KS2010: Security

Posted Nov 5, 2010 15:55 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> if you don't feel and responsibility for anyone but your users [...]

so first it's our fault that our code isn't accepted in vanilla for whatever reasons then it's also our fault that we still dare to make it available for anyone who cares. and to crown the absurdity, we're at fault for caring about these people. man, are you sure you have anything to do with security? i'm seriously worried about *your* users.

> [...]and have no intent to try and push the fixes upstream

maybe you're not a native speaker, but if you re-read spender's post carefully, you'll note that he made the cooperation conditional. it's the sentence that starts with the 'if' word, i'm sure you'll be able to find all one instance of it.

> [...]then your tree just became pretty irrelavent to linux security for anyone except for your users.

wait, are you saying grsec *was* relevant up to this very moment in time for anyone but grsec users? wow, i take it you won't elaborate but i smell magic here.

> even though you will make a lot of noise each time someone recreates your work

only if they 'forget' to credit the people for the ideas and/or the code or if they fuck up the implementation. just ask ingo ;).

KS2010: Security

Posted Nov 5, 2010 16:25 UTC (Fri) by PaXTeam (guest, #24616) [Link] (2 responses)

> I haven't found the scripts for regenerating e.g. the _ops constification either - it's not that it's really hard to re-create them, but it's stupid to duplicate such work.

it's more work than you think, just talk to Emese about it. afaik, she still has the cocci scripts that she used for the initial patch series then she had to manually fix up things here and there (i.e., there's no substitute for a make allmodconfig ;). the current const patches are about 230k but they only represent a small fraction of 200 or so ops structures that could probably be all constified. good luck getting that work done!

KS2010: Security

Posted Nov 6, 2010 9:52 UTC (Sat) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

Ah, I don't know why I somehow thought the constification was made using the "simple/ugly" script mentioned by Brad in http://lwn.net/Articles/346299/ . It's all good if the patches are created with Coccinelle.
Thanks for the clarification :)

I haven't seen any reply about the broken-out form, if any, of the large grsecurity patch ?

KS2010: Security

Posted Nov 6, 2010 11:19 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> Ah, I don't know why I somehow thought the constification was made using the "simple/ugly" script mentioned by Brad

multiple people worked on this over time with different methods and eventually there was some evolution in that coccinelle proved smarter than grep/sed ;). note that it's still not all roses as according to Emese coccinelle has (or used to have, i'm not following this nowadays) some limitation in how it parsed include files (no recursion was the big problem, iirc) so when you do not only want to generate patches for specific structures but also want coccinelle to determine which ones could be constified at all automatically, then you'll have some extra work to do (or find/write another tool). and you'll want this level of automated help as checking every usage of those 200 ops structure types by hand is anything but fun (and no, compiling allyesconfig/allmodfconfig doesn't necessarily give you 100% coverage).

> I haven't seen any reply about the broken-out form, if any, of the large grsecurity patch ?

because there's no such thing, at most the const patches exist standalone but not the rest.

KS2010: Security

Posted Nov 5, 2010 17:16 UTC (Fri) by kees (subscriber, #27264) [Link] (2 responses)

One thing I would note is that no one seems to have made the distinction between reactive security and proactive security (or I have missed it). Allowing "reactive security" to mean "security" is where the "security bugs are just bugs" culture starts from. Proactive security isn't about bugs in the code, it's about design failures. Fixing flawed design is an entirely different kind of thing.

On the reactive security front, upstream does an okay job; small obvious fixes are taken quickly, though sometimes larger fixes take some time to stew, but are ultimately taken. I'll skip talking about how fast reactive security handling by upstream has almost nothing to do with actually protecting end-users from the window of vulnerability, though.

On the proactive front, things are not as good. There has not been much distinction made between protecting userspace and protecting the kernel itself. Nearly all the proactive security work has been to protect userspace from itself, rather than protecting the kernel from userspace.

Small simple changes are done (limiting VFS, and now network, data lengths to below MAX_INT, for example), but larger architectural changes are frequently rejected or forgotten. (For example, why is module NX/RO http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-t... not in Linus's tree after 9 months? What happened to "mode 2 SECCOMP" http://lkml.org/lkml/2009/5/7/479 ?)

It seems that there is a pervasive conservatism when it comes to proactive security improvements (both userspace-defensive and kernel-defensive), and only core maintainers have the ability to change that.

KS2010: Security

Posted Nov 7, 2010 21:27 UTC (Sun) by foom (subscriber, #14868) [Link] (1 responses)

Kees just posted a blog entry and lkml post announcing an intention to work to push the grsec patches upstream:

http://www.outflux.net/blog/archives/2010/11/07/security-...
http://lkml.org/lkml/2010/11/7/113

Awesome!

KS2010: Security

Posted Nov 8, 2010 6:32 UTC (Mon) by Lionel_Debroux (subscriber, #30014) [Link]

Great :)

I posted three small constification patches to kernel-janitors and Cc LKML yesterday - but for users' protection, the authors of the patches getting in are much less important than the fact the patches _really_ get in :)
As noted by Brad above, and in my mails, non-const instances of constifiable structs have been added post-2.6.35, although these structs were already checked for by checkpatch.pl... not good.

Getting the constification patches in will reduce the number of files touched by the grsecurity patch: it's not unusual for the constification to be the only set of changes affecting a given file.

KS2010: Security

Posted Nov 4, 2010 20:15 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

Yeah, moving some uncontroversial (it would seem) bits of the grsecurity patch into mainline can both increase mainline security a bit and reduce a bit the size / ease a bit the maintenance of the grsecurity patch against a moving mainline.

For proper credit attribution, it requires coordination with the grsecurity people. Which I probably won't have time to do until next week, so feel free to beat me :)

KS2010: Security

Posted Nov 4, 2010 20:16 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

Thanks for your explanation :)