From owner-freebsd-security@FreeBSD.ORG Tue May 29 10:49:00 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5F8316A566 for ; Tue, 29 May 2007 10:49:00 +0000 (UTC) (envelope-from zhouzhouyi@ercist.iscas.ac.cn) Received: from ercist.iscas.ac.cn (ercist.iscas.ac.cn [124.16.138.3]) by mx1.freebsd.org (Postfix) with SMTP id 317DE13C457 for ; Tue, 29 May 2007 10:48:57 +0000 (UTC) (envelope-from zhouzhouyi@ercist.iscas.ac.cn) Received: (qmail 18221 invoked by uid 98); 29 May 2007 10:46:45 -0000 Received: from 124.16.138.62 by ercist.iscas.ac.cn (envelope-from , uid 89) with qmail-scanner-1.25 (spamassassin: 3.1.0. Clear:RC:1(124.16.138.62):SA:0(0.0/10.0):. Processed in 0.613765 secs); 29 May 2007 10:46:45 -0000 X-Spam-Status: No, hits=0.0 required=10.0 X-Qmail-Scanner-Mail-From: zhouzhouyi@ercist.iscas.ac.cn via ercist.iscas.ac.cn X-Qmail-Scanner: 1.25 (Clear:RC:1(124.16.138.62):SA:0(0.0/10.0):. Processed in 0.613765 secs) Received: from unknown (HELO zzy.H.qngy.gscas) (zhouzhouyi@ercist.iscas.ac.cn@124.16.138.62) by 0 with SMTP; 29 May 2007 10:46:44 -0000 Date: Tue, 29 May 2007 18:50:33 +0800 From: zhouyi zhou To: freebsd-pf@freebsd.org Message-Id: <20070529185033.39bf3222.zhouzhouyi@ercist.iscas.ac.cn> In-Reply-To: <20070528120029.DFCCB16A5BC@hub.freebsd.org> References: <20070528120029.DFCCB16A5BC@hub.freebsd.org> Organization: Institute of Software X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org Subject: (Security Regression Testsuites)Request for comments X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2007 10:49:00 -0000 Dear All, I am a student enrolled google summer code 2007. My job is to write security regression testsuites for FreeBSD under the guidance of my mentor Dr. Robert Watson. Under his encourage, I write following request for comments RFC :-) ////////////////////////////////////////////////////////////// What I plan to do: 1) to test the stability of Mandatory Access Control and Audit Subsystem for FreeBSD and TrustedBSD. Backgroud: a) there are many other modules in FreeBSD such as PF¡¢IPFW and IPSec and VIMAGE have had ignored the existance of Mandatory Access Control, they generate mbuf without a tag for Mandatory Access Control. Many of these has been corrected. b) The audit subsystem's handling of auditing disk full is wrong in locking vnodes 2) to test the correct enforement of various of access control (Mandatory Access Control, ACL, and priviledges in jail). Goal: To prevent the access right violation of the designer's intension 3) the consistency between the Mandatory Access Control Label generated by userland application and the label kernel actually handles. 4) to test the various of Firewalls and IPSec /////////////////////////////////////////////////////////////// What I have done: 1) investigate the Linux Test Project, especially for SeLinux 2) investigate the stress2 package for FreeBSD 3) summary the reason and the settlement of the confliction between Mandatory Access Control and PF, IPFW, IPSEC and VIMAGE 4) write a pair of pseudo ethernet pairs following the idea of another Socer Dr. Nanjun Li and Oreilly's , so that the network tests can be done in a single machine /////////////////////////////////////////////////////////////// Where I am still confused: 1) Which area and direction should I focus. The security subsystem in FreeBSD is large, which area deserves a testsuite in higher priority. 2) The general structure of the testsuite: Will it be a userland application package like stress2, or include a kernel module cooperation (like security/mac_test) 3) How to write a testsuite that will prevent the furthor violation of security instead of test the cases which are already corrected. PF¡¢IPFW and IPSec have already corrected their confliction with Mandatory Access Control, I think the testcases for the already corrected problems will not discover the newly generated problems, for example: test case for the PF's synproxy state rule only verify PF have correctly add a correct tag for Mandatory access control in function pf_send_tcp, how we discover a problem which may create in the future by means of create a mbuf without a correct tag for Mandatory access control in a new function? /////////////////////////////////////////////////////////////////// Finally I owe greatly thanks for various kind of suggestions not limited to above Sincerely yours Zhouyi Zhou Insitute of Software Chinese Academy of Sciences