From owner-freebsd-arch@FreeBSD.ORG Tue Dec 30 20:52:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D377DB7 for ; Tue, 30 Dec 2014 20:52:31 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EBED2491 for ; Tue, 30 Dec 2014 20:52:31 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id f51so10678286qge.7 for ; Tue, 30 Dec 2014 12:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-type; bh=adudmKJ1Hedf8I3A0XjCzJ8eXaR36qrC7nycYktjNhk=; b=UAjTIO1akTkFOvXE0vqfOQvsxH/+2sUF1gT34pDDuUdvYJxQ4SYkhOEgU2z7VEKLSV zYGK7iDomVQmlDpcuHChHeM43wXFE5QbOzFMpsnvR6xMsYpKPfDo5yFQGBc4hFDgboaw uRMvkiTxnLYQWmhLty5ZQK3OEy6yp4ecNgRJ4gNXr44ZR3OF0a1/uriqhW10MGY7Y5yq k/JTEyYXaN+9MA8Ec0D93LruDbb6esUr8Z66kU6jF34F7FPvy1GbXTn5Nq6qDzoQDGOR sPM10/iocs4gjAQxhnmPa7WyVw/5iOeghk3Z+O8eYwoDh7xkOyr6WYTeBF2iVPPc0jwv bpZQ== X-Received: by 10.224.51.11 with SMTP id b11mr103872552qag.43.1419972750132; Tue, 30 Dec 2014 12:52:30 -0800 (PST) Received: from shawnwebb-laptop.localnet ([73.173.99.185]) by mx.google.com with ESMTPSA id z5sm12341463qal.11.2014.12.30.12.52.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 12:52:29 -0800 (PST) From: Shawn Webb To: Konstantin Belousov Subject: Re: Disabling ptrace Date: Tue, 30 Dec 2014 15:52:25 -0500 Message-ID: <2246813.ih6odxTDOy@shawnwebb-laptop> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141230204445.GM42409@kib.kiev.ua> References: <20141230111941.GE42409@kib.kiev.ua> <29058.1419970932@chaos> <20141230204445.GM42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12681899.qa3kkoyJ5M"; micalg="pgp-sha256"; protocol="application/pgp-signature" Cc: freebsd-arch@freebsd.org, Jilles Tjoelker , "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 20:52:31 -0000 --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 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--