[grsec] Q. 'const'antify the members of a structure

[pageexec at freemail.hu]

On 27 May 2010 at 12:31, J. R. Okajima wrote:

> The grsec/pax patches make member of struct brabra_operation 'const.'
> I don't understand why they need these 'const'. They modifies some of
> structures, but other structures.
> What do they want to protect from what?

the goal is to reduce the number of writable function pointers which is
part of a larger strategy for kernel self-protection.

> From my point of view, the keyword 'const' is essentially a feature of C
> language and it never modifes the behaviour of software. It just
> prohibits the assignment (or modification) to a variable which is
> expected not to be modified.

you're talking about the human point of view, but that's only part of the
whole picture, the machine point of view is quite different in fact. in
particular it's up to the toolchain and runtime environment to actually
enforce the const (read-only) property of code/data. as you may have inferred
it by now, PaX (and in particular KERNEXEC) does exactly that. even vanilla
kernels have been able to do this partially (DEBUG_RODATA) for a while now.

> In other word, it is a feature for programmers and doesn't enhance the
> security level. Actually programmers can bypass 'const' easily by
> indirect assignment.

try that under KERNEXEC (or even DEBUG_RODATA) and report back the results ;).

> Also the grsec/pax patches modifies some assignments to the member
> of struct brabra_operation in mainline kernel, but they don't make the
> confirmation fot that.

what makes you think that we don't do that? there are many things in PaX
that assume certain 'invariants' in the kernel that have to be verified
*manually* for each release. that's one reason why porting PaX is not a
trivial business for example. so you can rest assured that we are very
much aware of what dangers the 'forking' of such an ops structure presents
and we check for changes each time we make a forward port.