Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Dec 2014 22:44:45 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        "Simon J. Gerraty" <sjg@juniper.net>
Cc:        freebsd-arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, Shawn Webb <lattera@gmail.com>
Subject:   Re: Disabling ptrace
Message-ID:  <20141230204445.GM42409@kib.kiev.ua>
In-Reply-To: <29058.1419970932@chaos>
References:  <20141230111941.GE42409@kib.kiev.ua> <20141230140709.GA96469@stack.nl> <3368390.qHnOScdmzK@shawnwebb-laptop> <29058.1419970932@chaos>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 30, 2014 at 12:22:12PM -0800, Simon J. Gerraty wrote:
> Shawn Webb <lattera@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.

> 
> 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).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141230204445.GM42409>