thr3ads.net - freebsd security - MAC problems [Sep 2003]

If this information is useful, please help other people find it:
Share via:

Jarosław Nozderko

2003-Sep-03 00:10 UTC

MAC problems

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

Robert Watson

2003-Sep-03 18:35 UTC

head link

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

Jaroslaw Nozderko

2003-Sep-08 06:36 UTC

head link

MAC problems

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
>
>

Jaroslaw Nozderko

2003-Sep-18 04:20 UTC

head link

MAC problems

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
> 
>

Reasonably Related Threads

Search for more reasonably related threads

freebsd security - Sep 2003 - MAC problems

MAC problems

MAC problems

MAC problems

MAC problems

Reasonably Related Threads