From owner-freebsd-bugs@FreeBSD.ORG Tue May 18 06:20:04 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9AE31065676 for ; Tue, 18 May 2010 06:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 980BA8FC14 for ; Tue, 18 May 2010 06:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4I6K4Xj000190 for ; Tue, 18 May 2010 06:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4I6K424000189; Tue, 18 May 2010 06:20:04 GMT (envelope-from gnats) Resent-Date: Tue, 18 May 2010 06:20:04 GMT Resent-Message-Id: <201005180620.o4I6K424000189@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Sarath.Babu@FreeBSD.org, Ranjith P Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 668291065680 for ; Tue, 18 May 2010 06:13:27 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 54ABF8FC08 for ; Tue, 18 May 2010 06:13:27 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o4I6DQiB004451 for ; Tue, 18 May 2010 06:13:26 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o4I6DQfu004450; Tue, 18 May 2010 06:13:26 GMT (envelope-from nobody) Message-Id: <201005180613.o4I6DQfu004450@www.freebsd.org> Date: Tue, 18 May 2010 06:13:26 GMT From: Sarath.Babu@FreeBSD.org, Ranjith P To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/146688: Integrity Violation in mac_biba module in FreeBSD X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 06:20:04 -0000 >Number: 146688 >Category: kern >Synopsis: Integrity Violation in mac_biba module in FreeBSD >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue May 18 06:20:04 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Sarath Babu, Ranjith P >Release: FreeBSD 8.0 >Organization: National Institute of Technology Calicut , India >Environment: FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: We feel that there is a problem in the 'mac_biba' module in FreeBSD 8.0. The user have a fredom to control the integrity level of files without any restrictions. The problem is this "Suppose there exist a user whose integrity level is 'biba/high'. Then the user creates a file which will get the integrity level of the user, i.e. 'biba/high'. Now the user and file are at the same integrity level. So the user can access the content of the file. Then the user can change the integrity level of the file. Suppose the integrity level of that file is changed to 'biba/low'. >From now onwards the user cannot access the file because the file is at low integrity level. But there exist a way in FreeBSD to change the integrity level back to 'biba/high' by changing the integrity level of user's shell. This can be done without the involvement of Administrator. Suppose the file is affected with some malicious information, at lower intgrity level, then it will go to higher level by this transition and a user at the higher integrity level can read this malicious information and the entire integrity get affected. i.e, The objects at lower integrity level can be easily trasferred to higher integrity level." >How-To-Repeat: Suppose the user has the integrity level 'biba/high' Step 1: Create a file $ echo "testing biba" > file Step 2: Read the file $ cat file Step 3: Read the integrity level of file $ getfmac file Step 4: change the integrity level of file to 'biba/low' $ setfmac biba/low file Step 5: Read the file $ cat file (now the output is "Permission Denied") Step 6: Change the integrity of User shell $ setpmac biba/low bash Step 7: Read the file $ cat file (The file can be successfully read) Step 8: Change the integrity level of file to 'biba/high' $ setfmac biba/high file (Here we observed the problem. The file is going to higher integrity level) Step 9: Exit the shell from lower integrity level $ exit Step 10: Read the content of file again $ cat file (Now the file can be successfully read. The file is actually came from lower integrity level) >Fix: The transition should be done in a controlled manner. The administrator involvement is recommended for a transition from lower to higher integrity level. For this there should be an administrator verification module. When the subject issues a command for changing the integrity level of user, this should be passed to the administrator verification module. Then this module will check whether the resulting transition will cause harm to the entire system. If there is no harm then the module will allow the transition else an error message will be passed to the user. A demand give mechanism can also be used here. Whenever the subject want to change level it can request to the administrator and if possible the administrator can give required permission. We want to know whether this problem is a valid one or not. If it is a valid one we want to correct it. Also we like to know more about the implementation of biba modules and the concept of compartments. Thank you. Sarath Babu & Ranjith P >Release-Note: >Audit-Trail: >Unformatted: