Disabling ptrace

[Shawn Webb]

On Tuesday, December 30, 2014 10:44:45 PM Konstantin Belousov wrote:
> On Tue, Dec 30, 2014 at 12:22:12PM -0800, Simon J. Gerraty wrote:
> > Shawn Webb <lattera at gmail.com> wrote:
> > > I'm curious what the use case was that brought this up. And why the
> > > requester thinks it's actually useful.
> > 
> > Being able to disable ptrace is useful - provided it cannot be bypassed.
> > In Junos we leveraged the signed binary implementation (based on NetBSD's
> > verified exec) to tag processes for which ptrace should fail.  The
> > signed binary stuff also supposed to prevent games with LD_PRELOAD -
> > assuming we didn't provide and sign the lib in question.
> 
> Look.  If somebody can preload a library into the process, or arbitrary
> modify the text segment, circumventing ptrace(2) ban is a least worry.
> The reference to the "Old New Thing" blog I posted before explains
> that with with fireworks, based on real 'security reports' sent to the
> security team at MS.

I asked about use case mainly because the applications I'm familiar with that 
care about disabling debugging facilities are ones that are trying to deter 
reverse engineering. Which is silly.

Disabling ptrace, though, is a great idea overall. I'm all for it. Tools like 
libhijack work only through ptrace. Disabling ptrace would also disrupt tools 
like libhijack (a good thing).

My only concern was the use case of anti-reverse engineering. Disabling ptrace 
in that case is useless.

> 
> > When we re-implemented veriexec as a MAC module, the above was left out,
> > in anticipation of using a separate module (though perhaps still
> > leveraging veriexec to set the labels).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141230/a5bc7e96/attachment.sig>