| 1 |
On 15 Feb 2008 at 8:25, Geoff Kassel wrote: |
| 2 |
|
| 3 |
> Hmm... what about a store-to-disk serialisation of the affected process and |
| 4 |
> running dependencies? (I'm thinking along the lines of certain fault-tolerant |
| 5 |
> kernels that do check-pointing of memory state here.) This is so that |
| 6 |
> application state can be restored from disk if required by an administrator. |
| 7 |
|
| 8 |
that would work except writing something like that is very hard, definitely |
| 9 |
beyond my time just for the sake to handle something that a coredump |
| 10 |
accomplishes well sans resurrection ability. |
| 11 |
|
| 12 |
on a sidenote, why would it be acceptable to store a process image on disk |
| 13 |
whereas a coredump isn't? |
| 14 |
|
| 15 |
> I know I'm speaking from a position of ignorance of the inner workings of PaX |
| 16 |
> here, but what if in the case of a non-executable page fault (this being the |
| 17 |
> case I'm more concerned about) the non-executable marking could be overridden |
| 18 |
> at the discrestion of the administrator (or preset new PaX marking) in order |
| 19 |
> to allow the process to continue? I'm thinking about cases like Mono and |
| 20 |
> Java, which seem (to my inexperienced eye) to be trying to execute data |
| 21 |
> segments containing generated code, because they're compiling said code at |
| 22 |
> run-time. |
| 23 |
> |
| 24 |
> If there could be a check so that the page being marked executable is one that |
| 25 |
> belongs to the fault-triggering process, that would handle these cases in an |
| 26 |
> admittedly less secure, but a more useable way. |
| 27 |
|
| 28 |
uhm, but you already have such a control over per-process PaX features. |
| 29 |
either paxctl (which marks the executable's ELF header) or MAC system |
| 30 |
(both grsec and RSBAC provide controls). or i must be not getting your |
| 31 |
problem ;-). |
| 32 |
|
| 33 |
-- |
| 34 |
gentoo-hardened@l.g.o mailing list |
Archives