Date: Mon, 8 Sep 2003 15:36:02 +0200 From: "Jaroslaw Nozderko" <jaroslaw.nozderko@polkomtel.com.pl> To: "Robert Watson" <rwatson@freebsd.org> Cc: freebsd-security@freebsd.org Subject: RE: MAC problems Message-ID: <2A857CE92C11FE40858689CAEC7BED49056D5B7A@E2K2.corp.plusnet>
next in thread | raw e-mail | index | archive | help
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ław Nozderko > Cc: freebsd-security@freebsd.org > Subject: Re: MAC problems > > > > On Wed, 3 Sep 2003, [iso-8859-2] Jarosław 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: > > > > 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="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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A857CE92C11FE40858689CAEC7BED49056D5B7A>