FreeBSD version: 5.1-RELEASE Hi, 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 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) 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. Regards and thanks for any help, Jarek
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 lossThe 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
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 > >
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, but it had no effect. The most likely explanation is that I made 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?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 > >