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

[Geoff Kassel]

> note the 'sans resurrection ability' above ;). coredumps are for post
> mortem analysis only.

Okay, then my original point stands - memory check-pointing or 
serialisation-to-disk on fault is useful, because they give a chance to 
revive a process which has been terminated because of a security violation - 
which is likely not have been the user-desired outcome.

> trust me, you don't want to resurrect from an exploit attempt ;)

With a memory check-pointing system, you could resurrect safely from a stage 
prior to the successful exploit - i.e. prior to the insertion or execution of 
the malicious code. With PaX guarding the system, you know when the exploit 
has occurred, because a stack smashing or similar exploit technique gets 
blocked by PaX. You can then resume the affected process from the check point 
immediately prior to the exploit attempt in a limited VM for safety (so that 
the exploit achieves nothing, if the vector is still present), allowing the 
user the chance to rescue any pertinent data, and exit 'normally'.

> it's the exact opposite: you keep the basic non-exec page implementation
> but omit the strict access control over it (MPROTECT) so that properly
> written apps can generate code at runtime.

How embarrassing. I'm still misunderstanding the workings of PaX. Thanks for 
the clarification.

> it's obviously possible but it raises more problems than it solves. for
> one, who would make the decision about forward progress? it obviously can't
> be the process itself as it's jut got suspended, so it must be some
> external monitor or a human. in either case, on what grounds would they
> make this decision? either has various failure modes that would nicely
> allow an exploit to succeed.

I was talking about an external monitor with some human intervention, yes. The 
grounds by which the external monitor makes decisions - automated or 
otherwise - depends on pre-determined security policy extensible on-the-fly, 
with a hard-coded minimum set of rules to keep the core utilities running 
safely and securely. (How I gather SELinux works, barring the on-the-fly 
extensibility.) Rules for applications start out with values deemed safe by 
the community (or the enterprise security administrator), but a user with 
sufficient privileges may override them when such restrictions become 
bothersome - at their own risk, of course.

Some things may not be allowed to be overridden at all, such as stack-smashing 
attacks - because there's no way ordinarily to safely restore from these. 
(Besides rolling back to a known-good memory check-point, if that capability 
exists.) Other less-critical conditions may be announced or just flagged 
silently on a per-application or user basis, depending on personal preference 
or other damage-limiting environmental factors. (i.e. no network or file 
access for the process because of MAC restrictions, etc.)

Does this make more sense?

I'm curious as to what failure modes you see, though. I see social engineering 
attacks, like those currently with the Windows Firewall/Vista UAC (malware 
that leads with 'when prompted, click allow access' before attempting a 
suspicious activity.) This works in Windows because nearly every user is 
running as an administrator, so no further action is required to allow a 
suspicious activity to proceed. In Unix-style systems, this isn't so 
effective, because a separate step of privilege escalation is needed.

This extra step gives the user more time to think about what they're doing, 
and perhaps enough hesitation to force a consult with someone who knows what 
should be done before proceeding to override the default security settings.

What other possible attacks have I missed?

On Fri, 15 Feb 2008, pageexec@××××××××.hu wrote:
> On 15 Feb 2008 at 14:14, Geoff Kassel wrote:
> > > 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.
>
> note the 'sans resurrection ability' above ;). coredumps are for post
> mortem analysis only.
>
> > Memory check-pointing to disk for quick recovery from critical faults
> > (such as power failure or exploit attempts)
>
> trust me, you don't want to resurrect from an exploit attempt ;)
>
> > > 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.
>
> it's the exact opposite: you keep the basic non-exec page implementation
> but omit the strict access control over it (MPROTECT) so that properly
> written apps can generate code at runtime. Java et al can these days work
> with only MPROTECT disabled, that wasn't always true due to various bad
> implementation issues (e.g., for a long time libjvm.so used to have some
> FPU initialization code in its .data segment, that didn't get far under
> PaX as you can imagine ;). in an ideal world the non-exec options would
> just be permanently enabled and only MPROTECT would be a real choice.
>
> > 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.
>
> it's obviously possible but it raises more problems than it solves. for
> one, who would make the decision about forward progress? it obviously can't
> be the process itself as it's jut got suspended, so it must be some
> external monitor or a human. in either case, on what grounds would they
> make this decision? either has various failure modes that would nicely
> allow an exploit to succeed.

-- 
gentoo-hardened@l.g.o mailing list