The issue in fact belongs to hardened kernel only, but I haven't found any specific guidelines on error reporting in hardened sub-projects, hence I use "generic" approach. Setting kernel.grsecurity.grsec_lock to non-zero value in linux-2.6.27-hardened-r2 doesn't lock any grsecurity settings. I haven't tried linux-2.6.27-hardened-r3, but looking at the code it seems it is also affected. After very brief code analysis it seems that the following happens (line numbers and file names are given for linux-2.6.27-hardened-r3): 1) grsec_lock seems to be analyzed at only one place: grsecurity/grsec_sysctl.c, function gr_handle_sysctl_mod, line 15. Note "op & MAY_WRITE" expression. 2) The only place gr_handle_sysctl_mod is called is at kernel/sysctl.c, function sysctl_perm_nochk, line 1735. Notice "op" parameter passing. 3) The only place sysctl_perm_nochk is called is at kernel/sysctl.c, function parse_table, line 1631. Notice MAY_EXEC passed as op parameter. This brings me to conclusion that expression in (1) can never be true (as MAY_EXEC and MAY_WRITE are bitwise exclusive), which is confirmed by actual sysctl behavior.
Not a security issue, reassigning to hardened/kernel. And I don't see why this need to be restricted, but I'll let the maintainers deal with that.
We don't have any secrets. If it's broke lets fix it.
it was the result of a bad forward port/merge, fixed in the last grsec patch for .27.8. issues like this are best addressed directly to spender btw ;).
hardened-sources-2.6.27-r4 is in portage with this fix, closing.
