Kernel security: beyond bug fixing

Posted Nov 4, 2015 12:30 UTC (Wed) by jezuch (subscriber, #52988)
In reply to: Kernel security: beyond bug fixing by liam
Parent article: Kernel security: beyond bug fixing

> Regarding conservatism: has any consideration been given to creation of a security tree, in similar fashion to the realtime tree?

And then spend a couple of decades trying to merge it back? :)

Kernel security: beyond bug fixing

Posted Nov 4, 2015 19:39 UTC (Wed) by liam (guest, #84133) [Link] (2 responses)

Well, maybe, but hopefully not:)
My thoughts were that having a place where security was the overriding factor would increase the pool of potential contributors, demonstrate the worth (and cost) of said changes (thereby mitigating concerns about performance/bugs rather than having such concerns stop development prematurely), and, in the meantime, act as the upstream for security related work (the later might be useful for folks interested in running such a kernel just as the rt branch is preferred by audio engineers).

Kernel security: beyond bug fixing

Posted Nov 4, 2015 19:45 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

isn't the grsecurity paxteam stuff an attempt to run a separate kernel security project?

what would be differetn about what you are proposing?

Kernel security: beyond bug fixing

Posted Nov 4, 2015 21:36 UTC (Wed) by liam (guest, #84133) [Link]

It would be something you could actually mention at conferences:)
More seriously, it would be very much like the rt branch where the intent is to upstream everything that can be upstreamed. In order to do this they'd need to have a good relationship with upstream.
Frankly, starting with the pax/grsec patches may not be a bad idea, but the work would need to be separated out into the smallest, useful components so as to make upstreaming more likely (I haven't examined there patches, so this work may already be in place).