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>