From owner-freebsd-security@FreeBSD.ORG Wed Sep 3 18:35:44 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0292216A4BF for ; Wed, 3 Sep 2003 18:35:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E79F443FBF for ; Wed, 3 Sep 2003 18:35:42 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h841YwrO000596; Wed, 3 Sep 2003 21:34:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h841Yv9Y000593; Wed, 3 Sep 2003 21:34:58 -0400 (EDT) Date: Wed, 3 Sep 2003 21:34:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: =?iso-8859-2?Q?Jaros=B3aw_Nozderko?= In-Reply-To: <2A857CE92C11FE40858689CAEC7BED4905558761@E2K2.corp.plusnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-security@freebsd.org Subject: Re: MAC problems X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2003 01:35:44 -0000 On Wed, 3 Sep 2003, [iso-8859-2] Jaros=B3aw Nozderko wrote: > I'm quite new to FreeBSD. I've check list archives and read a handbook, > but I didn't find solution to my problem and I hope this is not > off-topic. I've installed 5.1-RELEASE, enabled ACLs on the filesystems > and I wanted to test MAC features. I'm also new to MAC, so perhaps this > is some my mistake. When I enable mac_biba or mac_lomac (in > loader.conf) without any configuration, it seems to block networking:=20 > =20 > jarek@skorpion jarek> ping 192.168.65.100 > PING 192.168.65.100 (192.168.65.100): 56 data bytes > ping: sendto: Permission denied > ping: sendto: Permission denied > ping: sendto: Permission denied > ^C > --- 192.168.65.100 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss The default process label when you haven't configured per-user labels is a high integrity label in the Biba policy. The default label on network interfaces is low integrity. The result is generally a failure to be able to send on the network interfaces, although the failure mode varies a bit depending on the socket type, etc. For experimentation purposes, you'll probably want to set the following flag in loader.conf: security.mac.biba.trust_all_interfaces=3D"1" This will tell mac_biba that you want interfaces to be labeled as high integrity by default. You can also selectively change the security labels on interfaces using ifconfig: paprika# ifconfig wi0 maclabel 'biba/high(low-high)' paprika# ifconfig wi0 wi0: flags=3D8843 mtu 1500 inet6 fe80::209:5bff:fe31:27a4%wi0 prefixlen 64 scopeid 0x4=20 inet 192.168.5.3 netmask 0xffffff00 broadcast 192.168.5.255 ether 00:09:5b:31:27:a4 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid more-80211-in-bethesda 1:more-80211-in-bethesda stationname "FreeBSD WaveLAN/IEEE node" channel 3 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit maclabel biba/high(low-high) In the Biba policy, network interface labels have three elements: a single (effective) label, and low and high ends of a range. The single element is the default label for packets sourced from the interface; the low and high range elements place a bound on data allowed out the interface. The above labels incoming packets as high, and permits packets of any labels out the interface. > On the other side, when mac_mls is loaded, networking works, but > starting X server fails with message "Couldn't mmap /dev/vga" (I don't > see /dev/vga device regardless of MAC policy loaded) I seem to recall that the error message given by X is actually inaccurate:= =20 it reports a failure to mmap /dev/vga, but it's actually failing to mmap system memory. The default MLS label on user processes is mls/low -- since direct access to hardware of your system may leak information about higher confidentiality processes or data. As a result, the policy prevents you from doing so, which breaks X11. There are several approaches to resolving this: (1) Assign bypass labels to the special devices X accesses, so that processes can access the resources regardless of the label. This is a security hole, but for experimentation purposes, can be quite useful.= =20 I generally run the following script at boot on systems where this approach is used:=20 # Configure multilabel md-backed /tmp mdconfig -a -t swap -s 30m -u 10 newfs /dev/md10 tunefs -l enable /dev/md10 mount /dev/md10 /tmp mkdir /tmp/.X11-unix /tmp/.ICE-unix chmod 01777 /tmp /tmp/.X11-unix /tmp/.ICE-unix setfmac biba/equal,mls/equal /tmp /tmp/.X11-unix /tmp/.ICE-unix # Relabel entries in /dev so that X11 works (bypass protections) setpmac biba/equal,mls/equal setfmac biba/equal,mls/equal /dev/pci = \ /dev/io /dev/mem /dev/kmem /dev/sysmouse /dev/agpgart \ /dev/dri This assigns an "equal" (bypass) label to a bunch of device nodes accessed by X11. It also sets up /tmp with bypass labels so that X11 can dump its sockets there. (2) Assign a bypass label to the X server, so that it can access these resources while communicating with arbitrary user processes. To do this, the X server has to be started using: setpmac mls/equal /usr/X11R6/bin/startx Note that this also has the effect of bypassing MLS protection, but has different properties than (1). Your system resources are still protected by MLS, but the X server can now communicate with arbitrary processes, which might allow for information flow via the X server. Also, if your X server is compromised, the exploit code runs with a high level of privilege -- of course, that applies to (1) as well. (3) Only use the X server when running as mls/high, which will allow X to do what it needs to, but will limit what processes can talk to X, effectively meaning you can only X apps at mls/high. Currently, there is no open source multi-level X server that I know of, so if you run X on the machine, you do have to either play by the rules of MLS by running at a single level, or by bypassing the MLS policy selectively. I think it would be great to have open source MLS X server support, but it would be a fair amount of work. > Is it normal, or is something wrong ? Is any additional documentation > about MAC available, more than papers at http://www.trustedbsd.org ? I'd > like to learn a bit more.=20 There are man pages for each policy, a brief section in the FreeBSD Handbook summarizing the MAC policies, and several implementation papers. Currently, there are no tutorials for getting a system up and running -- these features are still considered experimental, and we've placed most of our focus on getting the features productionable and complete. However, we'd be happy to answer questions and fix bugs, as well as work towards having better documentation as we go along :-).=20 Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories