From owner-freebsd-arch@FreeBSD.ORG Tue Apr 6 15:48:42 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 810521065672 for ; Tue, 6 Apr 2010 15:48:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE428FC15 for ; Tue, 6 Apr 2010 15:48:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1A03A46B0D; Tue, 6 Apr 2010 11:48:42 -0400 (EDT) Date: Tue, 6 Apr 2010 16:48:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Churanov In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: New "scallhook" feature. Is is OK to create a proposal? 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, 06 Apr 2010 15:48:42 -0000 On Tue, 6 Apr 2010, Alexander Churanov wrote: > My friend, Vladislav Soldatov, and I are going to propose and implement a > new "scallhook" feature: the generic modular solution to monitoring, > filtering and translating system calls. > > The feature differs from OpenBSD systrace: it is much more general, going to > be modular and have strong foundation for security application. Hi Alexander-- This sounds like an interesting project. Could you say a bit more about how you envision such a system working, and in particular, how it might address concerns about the safety of the approach for some of the purposes you describe -- specifically, sandboxing. On the whole, OS vendors have eshewed the syscall wrapper approach due to its vulnerability to race conditions, and that concern would be critical concern in considering adopting any such system for FreeBSD. In fact, the MAC Framework, FreeBSD's extensible kernel security framework (now also used in Mac OS X), is specifically designed to avoid these sorts of races by offering integrated access to kernel data structures while holding appropriate locks. One of the ideas we have on the proposal ideas list is a path-based policy similar to Apple's Seatbelt policy module, offering lightweight sandboxing using path-based policy module. One caveat: our notion of "path" is a bit weaker than the abstraction of a path in Mac OS X, so some careful thinking woudl need to be done. Robert > > The project includes implementing the kernel-side code, the userland > configuration utility, some of most required filtering/translating modules > as well as a new handbook (otherbooks) section on configuration and > extending, plus articles on the web. The future additions to the project may > be a system for sandboxing application every time it is started and an > extension to ports system which would automatically sandbox application when > it is being installed. > > 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. > > What do you think of this? > Will be the feature accepted? > > Alexander Churanov > _______________________________________________ > 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" >