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

[Geoff Kassel]

> that would work except writing something like that is very hard, definitely
> beyond my time just for the sake to handle something that a coredump
> accomplishes well sans resurrection ability.

> on a sidenote, why would it be acceptable to store a process image on disk
> whereas a coredump isn't?

Hmm... I didn't know that you could restore a process fully from a core dump - 
hence the question. (My ignorance is showing again :) How interesting. In 
that case, there is no difference between the process image serialisation and 
the coredump, so I'm sorry for wasting your time on that hypothetical.

Memory check-pointing to disk for quick recovery from critical faults (such as 
power failure or exploit attempts) is on my Linux wish list, so I idlely like 
to find other justifications for it that'll convince others to implement it 
for me :) (I clearly don't have the in-depth kernel knowledge to implement it 
myself - yet.)

> uhm, but you already have such a control over per-process PaX features.
> either paxctl (which marks the executable's ELF header) or MAC system
> (both grsec and RSBAC provide controls). or i must be not getting your
> problem ;-).

Having read a little more deeply into the inner workings of PAGEEXEC, 
SEGMEXEC, and MPROTECT now, I see now what I was asking is already achievable 
by just by removing PAGEEXEC or SEGMEXEC protections for Java or Mono, but 
not MPROTECT. MPROTECT should stop any ill-behaved run-time compiled code 
from going out of bounds into other processes, while no execution limitations 
allows the run-time compiled code to execute normally. (If I understand 
correctly now.) Apologies for confusing you and wasting your time with a 
RTFM-type question.

However - while I temporarily have your ear :) I'm interested about being able 
to remove PAGEEXEC/SEGMEXEC and/or MPROTECT protections for a process in 
real-time - while a process is running, or in the hypothetical 'suspended 
awaiting administrative approval to continue' state I keep talking about. 

Is such a real-time removal of protections possible with the way PaX is 
currently implemented? If not, I think it'd be an interesting feature in the 
eventuality of such a process suspension feature being developed.

What are your thoughts on this? Am I just spinning more nonsense? :)

On Fri, 15 Feb 2008, pageexec@××××××××.hu wrote:
> On 15 Feb 2008 at 8:25, Geoff Kassel wrote:
> > 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 work except writing something like that is very hard, definitely
> beyond my time just for the sake to handle something that a coredump
> accomplishes well sans resurrection ability.
>
> on a sidenote, why would it be acceptable to store a process image on disk
> whereas a coredump isn't?
>
> > 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.
>
> uhm, but you already have such a control over per-process PaX features.
> either paxctl (which marks the executable's ELF header) or MAC system
> (both grsec and RSBAC provide controls). or i must be not getting your
> problem ;-).
-- 
gentoo-hardened@l.g.o mailing list