Date: Thu, 8 Apr 2010 19:42:24 +0400 From: Alexander Churanov <alexanderchuranov@gmail.com> To: Robert Watson <rwatson@freebsd.org>, "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: New "scallhook" feature. Is is OK to create a proposal? Message-ID: <z2x3cb459ed1004080842z805aa2abi13be2e87c280b859@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1004061633230.32745@fledge.watson.org> References: <s2u3cb459ed1004060627i98f7527at8275d9271bebb1e3@mail.gmail.com> <alpine.BSF.2.00.1004061633230.32745@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert, Warner, and the mailing list, Some things need to be clarified: 1) This is NOT a Google Summer of Code project and we are not students. 2) There are NO plans to create a wrapper for system calls. The feature should be an integral part of the kernel. 3) There are plans to avoid races by design. The feature is to be implemented into several steps: * Deal with direct arguments only. This is not hard and easy to get right. * Deal with indirect arguments of some calls by copying values. When passing control to the actual syscall, substitute original indirect arguments with copies. * Optimize indirect arguments handling by eliminating extra copies and processing. This is actually hard. It's necessary to mention that this is not an all-or-nothing project. The goal is to provide actually useful and safe features. It's expected that some calls may be left unhookable. 4) The quality is to be maintained by using automated unit-tests, integration tests, stress and capacity testing as well as utilizing working exploits for system call wrappers. 5) The feature will never provide privilege elevation (unlike systrace). It's intended to be more like securelevel and ulimit: there will be a single operation for adding a module to the list of hooks for the process. The lists, of course are inherited. The application will be unable to examine the list. We are going to create a page on FreeBSD wiki with details of the proposal: motivation, comparison to other security features, feature details, test plan and implementation plan. When the page is finished and before the implementation, we'd like to gather reviews of the plan. Then the information about progress will be posted periodically to the lists. If everything is right with the project, based on the information provided here, then we are going to proceed with the wiki. Should we go ahead? Alexander Churanov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?z2x3cb459ed1004080842z805aa2abi13be2e87c280b859>