Date: Tue, 30 Dec 2014 15:52:25 -0500 From: Shawn Webb <lattera@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: Disabling ptrace Message-ID: <2246813.ih6odxTDOy@shawnwebb-laptop> In-Reply-To: <20141230204445.GM42409@kib.kiev.ua> References: <20141230111941.GE42409@kib.kiev.ua> <29058.1419970932@chaos> <20141230204445.GM42409@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart12681899.qa3kkoyJ5M Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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@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). --nextPart12681899.qa3kkoyJ5M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJUoxCJAAoJEGqEZY9SRW7u9VoQAJBQxbXU918drc+/6q5gX1p4 3z4jiF/tGWM6KKT2McCRJhPaIrJ2YUg8986QbXewGpoTMIOM7kYGWba7SL7DpNc/ QIjmDoIcRNmYjWJuhcOE+vSXxOAATILCGCyH4F0jsn5zp0gFcZ/rpgBmub2m5Z9D 5y9N2McWySYDvaS0Yy/EsECDlb/9JQpqadCH80iAsH1DuCPr/GaUSFqpE/KSzdFe S1YrYj/FUizLjZp5ffF60E7e75jrP7HjgjWU1UZ4zGnnIx6lJhxh7s4ZToDniJRf M+lyJOHor2ZX9uioGA09/SsTKcWj9bmiykp0VmWwNC93M4Cq9FrB6nAuzxaxfF4E AzHc+CqqVw4grdc42zJu30gz+5zlrUFA8phqhpmjbGUD3pqsKlCeNSCLPZ0fOMJa rdWdy8mK1yYDiUYdU0F02ugzroPOVYGnlQdqVV1v59Nk+ttkGPivvMF/1jUJjpFn 2SDray6GTwLnWBooHg2+ig06LexouM5ObkDaQX/BEyecRuCsxBSlw1982rRHVVcY B0MMHRc12Cbl1J5pOWMgHqVxpm8yHxvU4OTqW+Y4EWcEe6n+XjYedNhjj/pkGVDC GODLMNJugszWXukwZJSXGrMdhFIsHNehqPafPAIAqOrOCXPIENJ8D5GHXuPo4bVl peXAozbu0c4v8peopSk5 =r1GY -----END PGP SIGNATURE----- --nextPart12681899.qa3kkoyJ5M--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2246813.ih6odxTDOy>