[grsec] Re: Re: Address space randomization?

[Mike Perry]

Thus spake pageexec at freemail.hu (pageexec at freemail.hu):

> and that's in fact the big difference between the old and the new markings,
> the new ones can explicitly enable/disable features and support two operating
> modes of PaX, i.e., they cover all possible combinations (default on/off and
> explicitly turned on/off), so it's logical (to me) that lack of such control
> information will result in a fallback to the normal kernel behaviour (which
> does nothing like PaX so no protections).

My primary complaint is that this total reversal in semantics was not
really documented clearly. But as a secondary complaint: You have
to consider user intuition when users see an option for "Soft mode"
which changes the default to non-enforced. It suggests that if this
setting is disabled, the default must be enforced.. However, even if
the user has upgraded their toolchain, the default is still NOT enforced
for applications that have yet to be recompiled. This is
counterintuitive, and at the very least should be documented with big
warning signs in all relevant locations.

> while your logic applies to your situation, it's not good in general as
> i explained it above.

Technically my situation is the same as that of anyone switching from
the old behavior to the new. Hence I would think my logic might be
followed by a great percentage of PaX/grsec users...

> > It would be nice if the help could be made a bit clearer, especially
> > since this vague wording caused me to come very close to a security
> > compromise during a recent attack on the system.
> 
> feel free to suggest a better language that in your opinion expresses the
> above and i'll put it in the next release (just try to keep it short ;-).

In CONFIG_PAX_EI_PAX I would suggest that the following paragraph

  You should enable this option only if your toolchain does not yet
  support the new control flag location (PT_PAX_FLAGS) or you still
  have applications not marked by PT_PAX_FLAGS.

be followed with:

  Note that applications that do not support the new control flag
  location will receive NO PROTECTION FROM PAX. This includes THIRD
  PARTY APPLICATIONS that may have been compiled with a legacy
  binutils. Hence if you have ANY legacy binaries, it is strongly
  recommended you enable this option for full protection.


Furthermore, I would suggest that CONFIG_PAX_PT_PAX_FLAGS be appened
with the following paragraph:

  Note further that applications that do not support the new control flag
  location will receive NO PROTECTION FROM PAX. This includes THIRD
  PARTY APPLICATIONS that may have been compiled with a legacy
  binutils. Hence if you have ANY legacy binaries, it is strongly
  recommended you enable the preceding option (CONFIG_PAX_EI_PAX)
  for full protection.


I recommend both places be changed lest someone come along and think
"Well, newer must be better" and simply enable the new support and
disable legacy suport. Perhaps such a user might even follow the
suggestion to upgrade their binutils, but neglect to recompile every
relevant executable on their machine.


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs