On Thu, 2017-04-27 at 19:11 +0000, Carsten Mattner wrote: > This is an undesirable situation for users, but I want to offer a > positive outlook on this. Ever since KSPP started, some of the > dynamics started to shift and I wager that closing off grsec will > motivate more users and developers to consider supporting efforts that > are in mainline linux. Short-term this is a problem and may require > relying and hoping 4.9-lts-grsec will be available and functioning. > When Bitkeeper licensing was revoked from the community, it didn't > take long for git to emerge. I see a similar pattern and high > potential for repetition of the same dynamics here. No grsec will > force people to either subscribe ala RHEL and hope spender is able to > fulfill his end of the contract or supporting KSPP and seamless LSM > integration in major distro packages. It's primarily not a technical issue, it's a political ones. As part landing mitigations upstream, they end up being watered down into slower, incomplete and/or weaker implementations. Lots has been outright rejected. Software implementations of SMEP and SMAP are not happening for i386 and x86_64. Proper slab sanitization was rejected. Proper page sanitization was rejected. RAP and SIZE_OVERFLOW upstream are pipe dreams. The REFCOUNT mitigation was rejected and is going to need to be done as opt-in, but they also blocked an efficient implementation like PaX and opt-in usage was rejected in the network stack, etc. due to the performance cost of their crappier implementation. A new refcount_t implementation may land, but there are a lot of politics involved and landing a migration from atomic_t to refcount_t across the kernel is going to be insanely slow and difficult. It has to be submitted bit by bit to different maintainers... and that's only the tip of the iceberg for these mitigations. It's realistically going to take 5+ years for KSPP to land everything other than RAP and SIZE_OVERFLOW and that's assuming it's extremely successful and the political issues are overcome. UDEREF/KERNEXEC will never land in their entirety and PaX and grsecurity are quickly moving targets. RAP didn't exist until recently, and it's now the flagship mitigation they offer. KERNSEAL/STRUCTGUARD won't have public code to copy... and neither will all of the other new stuff. No one else is doing compelling new kernel security research... so what happens once there's no longer public code to copy? It's literally a copy-paste job right now with bikeshedding of naming and kernel politics, and yet it's still going poorly. KSPP is quite useful and is improving things, sure. It's a joke to claim that it's going to be comparable to grsecurity though. > I must admit that spender may have started a process that will result > in arriving quicker at mainline kernel having a comparable set of > protections. Because as long as grsec was there and offered for > relatively recent kernels, there wasn't much motivation or arguments > to make to support a mainline reimplementation. > > I believe this will light a fire under KSPP and related community > driven projects. I can't see it going any faster than it already is, which is slow progress towards landing some things, with lots of setbacks and crippling of the features to make them acceptable upstream. I don't think there's any hope of landing mitigations like SIZE_OVERFLOW and RAP any time in the near future. RAP requires sweeping fixes of undefined behavior across the kernel, along with changes to calls/returns in all of the assembly code. SIZE_OVERFLOW is similar, but also requires many fixes of non-bugs. The only changes that have been successful landed upstream are those that are quite contained, or bits and pieces of ones that make wider changes in areas where the maintainers are active and see the value of it. Familiarity with what's actually happening and has happened already is needed to make any useful predictions about it. > I faintly remember when there was OpenGrsec because grsec was dead or > zombie but that was at least a decade ago and my memory is probably > incomplete. I can't find anything about that via searching for it. The grsecurity patches are also a lot different in terms of what they contain now compared to a decade ago. PaX started from NX emulation, inventing ASLR and other userspace mitigations but then ended up being focused on kernel self-protection and grsecurity similarly has a much different focus than it did in the past. They're much bigger today and they have a lot of complex, arcane code for architecture-specific mitigations. > I mean some grsec users might consider fleeing to HardenedBSD since > they provide a whole system like Hardened Gentoo, especially those > using grsec on hosting servers where the availability of jails, > capsicum, zfs, dtrace, ports and hardenedbsd may have already looked > enticing. HardenedBSD doesn't provide most of the grsecurity mitigations, including some of the most important / strongest mitigations like RAP.
Attachment:
signature.asc
Description: This is a digitally signed message part
