Created attachment 437878 [details, diff] patch file OpenAFS currently doesn't compile with grsecurity kernels for fairly trivial reasons. I've fixed them and am in the process of getting the patches submitted upstream, but it can be patched immediately in portage. This will also allow us to unmask it in hardened profiles.
Firstly, would you mind adding a link to the upstream bug/mailing list discussion so that we can track the status of upstream adoption? I'd like to get Bircoph's opinion, but my feelings are as follows: I'd love to include a patch for grsecurity support, but I'd rather add that patch when upstream has approved it (adding it so users can take advantage while waiting for the next upstream release to include it). The problem with applying a patch pending upstream approval, but currently without it is that they may recommend fixing it and then we'd have to rev bump again (potentially more than once) while you and upstream work out the final version. But like I said, I'd love to include the patch once upstream has approved it. So, please post a link so that we can track it, and then we can add it as soon as upstream gives the OK.
I agree with NP-Hardass that this patch needs to be discussed with upstream first. Frankly, I'm not an expert in grsecurity kernel code, so I can't apply a security-related patch without full understanding of all its implications. Also I'd like to hear from the hardened team, since their expertise in this matter will be valuable. Once this patch will be approved, I'd love to include it too.
Another aspect: openafs-kernel is not compatible with CONFIG_DEBUG_RODATA kernel feature. Does your patch handle this? Or how do you fix this issue? Maybe using fuse client? An ability to enforce kernel text and rodata read-only is quite important even on vanilla kernels, I'm sure it highly desired if not mandatory for hardened systems.
The grsec kernel has no need for CONFIG_DEBUG_RODATA since it has its own CONFIG_PAX_KERNEXEC that provides a superset of the functionality (and already works fine with OpenAFS). As for getting the patch submitted upstream, they don't seem to have a bug tracker, so I've emailed their dev mailing list, where I've already been in correspondence with them, with the patch (changed to work with their current development version of the code). I'll update once they get back to me. Also, I wouldn't call this a security-related patch, since all it does is fix the kernel config option detection, which fails in stock OpenAFS because it assumes all structs are non-const, and modify some struct initializations to use designated initializers, which grsec requires for struct randomization.
ML thread.
(In reply to Deven Lahoti from comment #4) > The grsec kernel has no need for CONFIG_DEBUG_RODATA since it has its own > CONFIG_PAX_KERNEXEC that provides a superset of the functionality (and > already works fine with OpenAFS). I don't understand this. If PAX_KERNEXEC is a superset of DEBUG_RODATA, then if code doesn't work with DEBUG_RODATA, it will not work with PAX_KERNEXEC. So either you fixed or workarounded this somehow, or PAX_KERNEXEC can't fully replace DEBUG_RODATA. > Also, I wouldn't call this a security-related patch, since all it does is fix > the kernel config option detection, which fails in stock OpenAFS because it > assumes all structs are non-const, and modify some struct initializations to > use designated initializers, which grsec requires for struct randomization. Let's say any grsecurity-related issue is security-related in a broad sense of security. I just want to be careful here. Anyway, thank you for your contribution; we are monitoring upstream progress now.
According to the PaX team, CONFIG_PAX_KERNEXEC is a strict superset of CONFIG_DEBUG_RODATA in functionality: https://forums.grsecurity.net/viewtopic.php?f=3&t=1630 Somehow, the different implementation means that it doesn't require a workaround for OpenAFS. I'm not an expert on grsec code, so I myself don't really know why.
Good. Actually, we have one more possibility left: DEBUG_RODATA check is outdated. It was introduced by bug 127084 10(!) years ago. Preliminary testing by NP-Hardass showed that module builds and loads fine with DEBUG_RODATA enabled. It looks like this issue was (silently) fixed by upstream or at least nobody noticed it (and I can't find it in upstream ChangeLog). This also perfectly explains why it works fine with PAX_KERNEXEC. Now we are doing further tests and investigation. It is likely that !DEBUG_RODATA restriction can and will be removed to improve kernel security for all our users.
!DEBUG_RODATA restriction is removed long time ago.
