Date: Thu, 18 Sep 2003 13:19:24 +0200 From: "Jaroslaw Nozderko" <jaroslaw.nozderko@polkomtel.com.pl> To: <freebsd-security@freebsd.org> Subject: RE: MAC problems Message-ID: <2A857CE92C11FE40858689CAEC7BED4905D7BF5B@E2K2.corp.plusnet>
next in thread | raw e-mail | index | archive | help
Hi, one more question: is there any detailed information on how to configure per-user MAC labels ? I've tried to put it in login.conf, as mentioned in man pages,=20 but it had no effect. The most likely explanation is that I made=20 something wrong, but I think nothing was reported in system logs. Thanks in advance for any help, Jarek > -----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 >=20 >=20 >=20 > On Wed, 3 Sep 2003, [iso-8859-2] Jaros=B3aw Nozderko wrote: >=20 > > I'm quite new to FreeBSD. I've check list archives and=20 > 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=20 > filesystems > > and I wanted to test MAC features. I'm also new to MAC, so=20 > perhaps this > > is some my mistake. When I enable mac_biba or mac_lomac (in > > loader.conf) without any configuration, it seems to block=20 > 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 >=20 > The default process label when you haven't configured=20 > 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=20 > failure to be able > to send on the network interfaces, although the failure mode=20 > varies a bit > depending on the socket type, etc. For experimentation=20 > purposes, you'll > probably want to set the following flag in loader.conf: >=20 > security.mac.biba.trust_all_interfaces=3D"1" >=20 > This will tell mac_biba that you want interfaces to be labeled as high > integrity by default. You can also selectively change the=20 > security labels > on interfaces using ifconfig: >=20 > paprika# ifconfig wi0 maclabel 'biba/high(low-high)' > paprika# ifconfig wi0 > wi0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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) >=20 > In the Biba policy, network interface labels have three=20 > elements: a single > (effective) label, and low and high ends of a range. The=20 > single element > is the default label for packets sourced from the interface;=20 > the low and > high range elements place a bound on data allowed out the=20 > interface. The > above labels incoming packets as high, and permits packets of=20 > any labels > out the interface. >=20 > > On the other side, when mac_mls is loaded, networking works, but > > starting X server fails with message "Couldn't mmap=20 > /dev/vga" (I don't > > see /dev/vga device regardless of MAC policy loaded) >=20 > I seem to recall that the error message given by X is=20 > actually inaccurate:=20 > it reports a failure to mmap /dev/vga, but it's actually=20 > 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=20 > 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: >=20 > (1) Assign bypass labels to the special devices X accesses, so that > processes can access the resources regardless of the=20 > label. This is a > security hole, but for experimentation purposes, can be=20 > quite useful.=20 > I generally run the following script at boot on systems where this > approach is used:=20 >=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=20 > /tmp/.ICE-unix > # Relabel entries in /dev so that X11 works (bypass=20 > protections) > setpmac biba/equal,mls/equal setfmac=20 > biba/equal,mls/equal /dev/pci \ > /dev/io /dev/mem /dev/kmem /dev/sysmouse=20 > /dev/agpgart \ > /dev/dri >=20 > This assigns an "equal" (bypass) label to a bunch of device nodes > accessed by X11. It also sets up /tmp with bypass labels=20 > so that X11 > can dump its sockets there. >=20 > (2) Assign a bypass label to the X server, so that it can access these > resources while communicating with arbitrary user processes. >=20 > To do this, the X server has to be started using: >=20 > setpmac mls/equal /usr/X11R6/bin/startx >=20 > Note that this also has the effect of bypassing MLS=20 > protection, but > has different properties than (1). Your system resources=20 > are still > protected by MLS, but the X server can now communicate=20 > with arbitrary > processes, which might allow for information flow via the=20 > X server. > Also, if your X server is compromised, the exploit code=20 > runs with a > high level of privilege -- of course, that applies to (1) as well. >=20 > (3) Only use the X server when running as mls/high, which=20 > 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. >=20 > Currently, there is no open source multi-level X server that=20 > I know of, so > if you run X on the machine, you do have to either play by=20 > 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=20 > MLS X server > support, but it would be a fair amount of work. >=20 > > Is it normal, or is something wrong ? Is any additional=20 > documentation > > about MAC available, more than papers at=20 > http://www.trustedbsd.org ? I'd > > like to learn a bit more.=20 >=20 > There are man pages for each policy, a brief section in the FreeBSD > Handbook summarizing the MAC policies, and several=20 > implementation papers. > Currently, there are no tutorials for getting a system up and=20 > running -- > these features are still considered experimental, and we've=20 > placed most of > our focus on getting the features productionable and=20 > complete. However, > we'd be happy to answer questions and fix bugs, as well as=20 > work towards > having better documentation as we go along :-).=20 >=20 > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A857CE92C11FE40858689CAEC7BED4905D7BF5B>