RE: MAC problems

• Previous message: Olafur Osvaldsson: "Re: ftp.freebsd.org out of date? (WRT security advisories)"
• Maybe in reply to: Jarosław Nozderko: "MAC problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 18 Sep 2003 13:19:24 +0200
To: <freebsd-security@freebsd.org>

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
>
>
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

• Previous message: Olafur Osvaldsson: "Re: ftp.freebsd.org out of date? (WRT security advisories)"
• Maybe in reply to: Jarosław Nozderko: "MAC problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]