MAC problems

Thu Sep 18 04:19:53 PDT 2003

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 at freebsd.org]
> Sent: Thursday, September 04, 2003 3:35 AM
> To: Jaros³aw Nozderko
> Cc: freebsd-security at 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 at 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 at fledge.watson.org      Network Associates Laboratories
> 
> 