MAC problems

[Robert Watson]

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