From owner-freebsd-arch@FreeBSD.ORG Tue May 18 19:13:11 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF3711065672 for ; Tue, 18 May 2010 19:13:11 +0000 (UTC) (envelope-from vsoldatov@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63B018FC1E for ; Tue, 18 May 2010 19:13:11 +0000 (UTC) Received: by fxm4 with SMTP id 4so79952fxm.13 for ; Tue, 18 May 2010 12:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=tNk/RYooPRx4qb4phyyjb3H+Eyf4J3FJi9UXkuV0hvM=; b=vXdm3ER4MF2g72qL8XMl2RDU2WwddEQwXe7n8x5ZQ9rKWkzrpeGoSJ+4iz4diJxrwU sYx4NMhtacJ1SzFAlmvNofr5Atcgmxs8AQrB2XbGJmM47jCyRDsVU3C4KgbtHsRCtjeL tA4vnLjf/UFn1GhFcT/dTesW9Kmq9idLNin+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=H8DrXgPusX5UFRPoZa5Mb6GQEPFf3h2ao6MOXS9/x19x2hx2mCWpCOmqZyUvfsPWSy YPFh5Lc+hs8JF5nJmvcwUYORdG9/4Y+LWf8UZ8K3e6q5RfGpOeC70wKhOx1v73AKtRxV Z77YcNLKiLPID5MuwukXfMf/mVXeo/3tz/xR4= MIME-Version: 1.0 Received: by 10.239.192.74 with SMTP id d10mr633812hbi.74.1274208250846; Tue, 18 May 2010 11:44:10 -0700 (PDT) Received: by 10.239.136.70 with HTTP; Tue, 18 May 2010 11:44:10 -0700 (PDT) In-Reply-To: <20100428120012.C900110656A9@hub.freebsd.org> References: <20100428120012.C900110656A9@hub.freebsd.org> Date: Tue, 18 May 2010 22:44:10 +0400 Message-ID: From: Vladislav Soldatov To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-arch Digest, Vol 365, Issue 2 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:13:12 -0000 On Wed, Apr 28, 2010 at 4:00 PM, wrote: > Send freebsd-arch mailing list submissions to > freebsd-arch@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > or, via email, send a message with subject or body 'help' to > freebsd-arch-request@freebsd.org > > You can reach the person managing the list at > freebsd-arch-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-arch digest..." > > > Today's Topics: > > 1. Re: New "scallhook" feature. Is is OK to create a proposal? > (Jeremie Le Hen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Apr 2010 18:54:31 +0200 > From: Jeremie Le Hen > Subject: Re: New "scallhook" feature. Is is OK to create a proposal? > To: Alexander Churanov > Cc: freebsd-arch@freebsd.org > Message-ID: <20100427165431.GQ34466@felucia.tataz.chchile.org> > Content-Type: text/plain; charset=us-ascii > > Hi Alexander, > > On Tue, Apr 06, 2010 at 05:27:29PM +0400, Alexander Churanov wrote: > > About me: > > > > I am software engineer, currently working in Cisco Systems, specializing > in > > C/C++/UNIX. My additional interests are software quality and security. I > am > > a port maintainer for devel/boost-* and was participating in extending > > syscons driver, until the project was superseded by syscons rewrite by Ed > > Schouten. > > > > About Vladislav: > > Vladislav is a PhD of computer science, has experience with developing in > C > > and C++ for FreeBSD. > > > > Before writing the full proposal on the wiki, I'd like to receive the > first > > approval. > > I don't know what you intend to do after Robert's reply but if you are > seeking a kernel-level security improvement to work on, I suggest to > look at porting PaX into FreeBSD. > > Regards, > -- > Jeremie Le Hen > > Humans are born free and equal. But some are more equal than others. > Coluche > > > ------------------------------ > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > End of freebsd-arch Digest, Vol 365, Issue 2 > ******************************************** > It seems to me that discussion on the new "scallhook" feature, proposed by my friend Alexander Churanov, has somehow frozen. We propose the following possible solutions to the problems, mentioned by Robert Watson. We propose to create a special procedure to control the "identity" of the object, to which the given indirect argument is pointing. For example, we can calculate the hash code of the string, that represents absolute path to the resource, before the policy checks done by the scallhook's modules are performed, and store it somewhere in the kernel space. When the actual system call is made, we compute it again and compare with the previously saved one. It is evident, that this procedure is not able to prevent the substitution of the object, for example, associated with the symbolic link. Nonetheless, it allows to "spot" indirect argument substitution and raise an error. Yes, this approach is intrusive and requires kernel source code changes. We prefer substitution detection over locking, because this allows policies to be implemented in user-space processes (for flexibility), as well as implemented in loadable kernel modules (for performance). While permitting implementation of the the policy check procedures in languages other than C and easy debugging, this approach prevents concurrency vulnerabilities by performing the argument identity check in kernel. Recently Jeremie Le Hen has mentioned a possibility of porting PaX from Linux to FreeBSD. Our aim is not just to port something to FreeBSD, but to create a general mechanism for secure system call interposition. PaX has a different functionality and can't be used to implement policy check logic of any kind or detect argument substitution in syscall wrappers.