From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 2 15:23:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD13C774 for ; Wed, 2 Jul 2014 15:23:57 +0000 (UTC) Received: from pps02.cites.illinois.edu (pps02.cites.illinois.edu [192.17.82.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79CA2218C for ; Wed, 2 Jul 2014 15:23:57 +0000 (UTC) Received: from chiht3.cites.illinois.edu (chiht3.cites.illinois.edu [64.22.177.75]) by pps02.cites.illinois.edu (8.14.5/8.14.5) with ESMTP id s62EqcAM025185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jul 2014 09:52:40 -0500 Received: from CITESMBX1.ad.uillinois.edu ([169.254.3.145]) by CHIHT3.ad.uillinois.edu ([64.22.177.75]) with mapi id 14.03.0181.006; Wed, 2 Jul 2014 09:52:38 -0500 From: "Dautenhahn, Nathan Daniel" To: "freebsd-hackers@freebsd.org" Subject: Kernel Privilege Separation Policy Thread-Topic: Kernel Privilege Separation Policy Thread-Index: AQHPlgVDGNIEiUh8hk6kgbH9TWcXPQ== Date: Wed, 2 Jul 2014 14:52:37 +0000 Message-ID: <100A360A-DF5E-46D5-83F0-BCAE672D1D6C@illinois.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.22.177.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6295A3A34E8E2C4D865B88BDB1BA8E9A@mx.uillinois.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407020167 X-Spam-OrigSender: dautenh1@illinois.edu X-Spam-Bar: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:23:57 -0000 Hi All- I am a graduate student at UIUC and am currently working on a system that isolates the MMU from the rest of the FreeBSD kernel. For the purpose of enabling privilege separtion within the kernel. - This code is approximately 3k lines. - This base system also provides kernel code integrity (write protection = in memory) as one of its base properties. - This is somewhat follow up work on previous publications VirtualGhost (ASPLOS '14) and KCoFI (IEEE SP '14). The new system uses similar MMU policies to create the isolation within the kernel. Controlling the MMU enables read/write protection policies (for memory page= s) to be enforced within the kernel itself. I am interested in thoughts from the community on how to best use an intra-kernel isolation and mediation mechanism? One example policy or use of this mechanism would be to place critical func= tion pointers into a write protected region of memory and apply a policy where function pointers (such as a system call function pointer) are only allowed= to be set once (a write-once policy). Some initial ideas I have include: - Protecting against common root kit behaviors such as system call hookin= g, character device hooking (protect function pointers), DKOM (modifying process lists to hide data), kernel object hooking, etc. - Protecting capabilty enforcement - Mandatory Access Control Mechanism enforcement - Auditing mechansims (to ensure integrity of audit logs) Does anyone have insight into these or other important uses of this type of system? What would be a "killer app" type use in the kernel? I can be available on IRC if a real time discussion seems like a better pla= ce for discussion. Thanks, ::nathan:: [I have posted this to both freebsd-hackers and freebsd-security lists =97 = I wasn=92t sure what was best]=