Re: [gentoo-hardened] Keeping gentoo-hardened alive (WAS: latest kernel exploit patch for vmsplice coming?)

[Geoff Kassel]

> coredumps are subject to the usual rlimit, so it's under userland control.

You're quite right, of course. I'd forgotten that this feature was tunable in 
userspace. (It seems I forget that about a lot of kernel features :)

> problem with this is DoS (exhaustion of RLIMIT_NPROC, not to mention all
> the memory and other resources used by the process).

Hmm... what about a store-to-disk serialisation of the affected process and 
running dependencies? (I'm thinking along the lines of certain fault-tolerant 
kernels that do check-pointing of memory state here.) This is so that 
application state can be restored from disk if required by an administrator. 
That would shift the DoS from process count limitations (which are deadly to 
normal system operation if exceeded, I know), to disk size limitations, which 
is a lot easier to manage automatically in real-time.

> probably not a problem
> for a malicious local user as he'll just lock himself out but for a system
> service (think apache or mysql) it is.

Perhaps this store to disk feature I mentioned could be a per-application 
userspace-controlled configuration option, ala my previous rants about 
customisable access control management?

Resource limitations could be part of the configuration.

> this is not possible as the page fault that triggered PaX would just
> occur again, ad infinitum. i.e., the userland process cannot make forward
> progress (the non-executable or unmapped page where the fault occured will
> stay so), the kernel must do something about it.

I know I'm speaking from a position of ignorance of the inner workings of PaX 
here, but what if in the case of a non-executable page fault (this being the 
case I'm more concerned about) the non-executable marking could be overridden 
at the discrestion of the administrator (or preset new PaX marking) in order 
to allow the process to continue? I'm thinking about cases like Mono and 
Java, which seem (to my inexperienced eye) to be trying to execute data 
segments containing generated code, because they're compiling said code at 
run-time.

If there could be a check so that the page being marked executable is one that 
belongs to the fault-triggering process, that would handle these cases in an 
admittedly less secure, but a more useable way.

What do you think?

> here's upstream ;-).

Thank you for your time in answering my questions and critiquing my ideas for 
new features :)

Kind regards,

Geoff Kassel.

On Thu, 14 Feb 2008, pageexec@××××××××.hu wrote:
> On 13 Feb 2008 at 15:07, Geoff Kassel wrote:
> > Speaking of PaX, another great, impossible thing would be to have a
> > kernel-level feature for handling PaX violations in a less violent manner
> > (core dumps are violent, in my mind)
>
> coredumps are subject to the usual rlimit, so it's under userland control.
>
> > - perhaps suspension of the process in question until investigated,
>
> problem with this is DoS (exhaustion of RLIMIT_NPROC, not to mention all
> the memory and other resources used by the process). probably not a problem
> for a malicious local user as he'll just lock himself out but for a system
> service (think apache or mysql) it is.
>
> > with the possibility of resumption
>
> this is not possible as the page fault that triggered PaX would just
> occur again, ad infinitum. i.e., the userland process cannot make forward
> progress (the non-executable or unmapped page where the fault occured will
> stay so), the kernel must do something about it.
>
> > (Perhaps I'm just unaware of an already existing feature.) Again, an
> > upstream issue.
>
> here's upstream ;-).
-- 
gentoo-hardened@l.g.o mailing list