From owner-freebsd-security@FreeBSD.ORG Mon Sep 8 06:36:09 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 01CD116A4BF; Mon, 8 Sep 2003 06:36:09 -0700 (PDT) Received: from plusmx1.polkomtel.com.pl (plusmx1.polkomtel.com.pl [212.2.96.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B11144001; Mon, 8 Sep 2003 06:36:07 -0700 (PDT) (envelope-from jaroslaw.nozderko@polkomtel.com.pl) Received: from mswwaw1.corp.plusnet (plus-96-118.polkomtel.com.pl [212.2.96.118]) by plusmx1.polkomtel.com.pl (Postfix) with ESMTP id 4DD9D38038; Mon, 8 Sep 2003 15:36:03 +0200 (CEST) Received: from E2K2.corp.plusnet (unverified) by mswwaw1.corp.plusnet ; Mon, 8 Sep 2003 15:36:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Sep 2003 15:36:02 +0200 Message-ID: <2A857CE92C11FE40858689CAEC7BED49056D5B7A@E2K2.corp.plusnet> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MAC problems Thread-Index: AcNyhOGaYEjllsGmR9e4V6BnG8+IyQDiOvFg From: "Jaroslaw Nozderko" To: "Robert Watson" 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: Mon, 08 Sep 2003 13:36:09 -0000 Hi Robert, thanks a lot for your help. Regards, Jarek Jaroslaw Nozderko GSM +48 601131870 / Kapsch (22) 6075013 jaroslaw.nozderko@polkomtel.com.pl IT/CCBS/RS - Analyst Programmer > -----Original Message----- > From: Robert Watson [mailto:rwatson@freebsd.org] > Sent: Thursday, September 04, 2003 3:35 AM > To: Jaros=B3aw Nozderko > Cc: freebsd-security@freebsd.org > Subject: Re: MAC problems > > > > 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 > > 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 > 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: > 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. > I generally run the following script at boot on systems where this > approach is used: > > # 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. > > 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 :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > >=20