Date: Wed, 17 Nov 2004 17:39:56 +0100 From: "Peter Harmsen" <pharmsen@horizon.nl> To: freebsd-questions@freebsd.org Subject: Re: MAC Message-ID: <opshma8u1z0df9kz@localhost.concepts.nl> In-Reply-To: <Pine.NEB.3.96L.1041117103151.59721E-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1041117103151.59721E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Robert,
I'm very pleased to hear about ktrace.I think i have a good chance to
tacle the spot
that regulates the allowable memory range which prevents XFree86 to work
in conjunction
with MAC.As far as the policy is concerned i'm using the default policy
from the FreeBSD
handbook,a little altered to suit my system.I don't use a LOMAC policy yet.
I used the following:
mac_biba_load="YES"
mac_mls_load="YES"
mac_seeotheruids_load="YES"
mac_partition_load="YES"
"The login class is required otherwise users will be refused access to
common commands such as vi(1). The following sh script should do the
trick:"
# for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \
/etc/passwd`; do pw usermod $x -L insecure; done;
I added the following insecure class to /etc/login.conf:
insecure:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
:manpath=/usr/share/man /usr/local/man:\
:nologin=/usr/sbin/nologin:\
:cputime=1h30m:\
:datasize=8M:\
:vmemoryuse=100M:\
:stacksize=2M:\
:memorylocked=4M:\
:memoryuse=8M:\
:filesize=8M:\
:coredumpsize=8M:\
:openfiles=24:\
:maxproc=32:\
:priority=0:\
:requirehome:\
:passwordtime=91d:\
:umask=022:\
:ignoretime@:\
:label=partition/13,mls/5:
While i still got the Xvidmem memory not in the allowable range error
mesage, i decided to
change stacksize=2M in stacksize=unlimited (default login class setting)
upto every setting
in /etc/login.conf i suspected to be the cause of the problem.
# This is the default BIBA/MLS policy for this system.
.* biba/high,mls/high
/sbin/dhclient biba/high(low),mls/high(low)
/dev(/.*)? biba/equal,mls/equal
# This is not an exhaustive list of all "privileged" devices.
/dev/mdctl biba/high,mls/high
/dev/pci biba/high,mls/high
/dev/k?mem biba/high,mls/high
/dev/io biba/high,mls/high
/dev/agp.* biba/high,mls/high
(/var)?/tmp(/.*)? biba/equal,mls/equal
/tmp/\.X11-unix biba/high(equal),mls/high(equal)
/tmp/\.X11-unix/.* biba/equal,mls/equal
/proc(/.*)? biba/equal,mls/equal
/mnt.* biba/low,mls/low
(/usr)?/home biba/high(low),mls/high(low)
(/usr)?/home/.* biba/low,mls/low
/var/mail(/.*)? biba/low,mls/low
/var/spool/mqueue(/.*)? biba/low,mls/low
(/mnt)?/cdrom(/.*)? biba/high,mls/high
(/usr)?/home/(ftp|samba)(/.*)? biba/high,mls/high
/var/log/sendmail\.st biba/low,mls/low
/var/run/utmp biba/equal,mls/equal
/var/log/(lastlog|wtmp) biba/equal,mls/equal
I enabled this policy with:
# setfsmac -ef /etc/policy.contexts /
# setfsmac -ef /etc/policy.contexts /usr
According to the FreeBSD handbook, /etc/mac.conf would require:
default_labels file ?biba,?mls
default_labels ifnet ?biba,?mls
default_labels process ?biba,?mls,?partition
default_labels socket ?biba,?mls
Since the default /etc/mac.conf is a complement of the above labels, i
left it as it was, perhaps,
i shouldn't.
On Wed, 17 Nov 2004 10:33:44 +0000 (GMT), Robert Watson
<rwatson@freebsd.org> wrote:
>
> On Tue, 16 Nov 2004, Peter Harmsen wrote:
>
>> I'm trying to implement a Mandatory Access Controll setup, just like the
>> one in the example of the FreeBSD handbook:15.14 Implementing a Secure
>> Environment with MAC".The graphics card setup itself is very straight
>> forward and didn't cause any problem(s).When i run "startx" i get the
>> following mesage:xf86Vidmem:Address 0xde601000 outside allowed range.
>> This must be a configure / policy error.What keeps me busy is the spot
>> where to change or add something in order to increase the allowable
>> memory range which is clearly regulated to much for getting xfree86 to
>> work ( with MAC,without it's a nobrainer)
>
> What policies are you currently enabling in your kernel? Some of them
> will limit access to device drivers, which may prevent X11 from accessing
> the devices, resulting in errors that are sometimes difficult to debug
> (for example, for several years, XFree86 would incorrectly report that
> access to /dev/vga was denied, when it was actually /dev/io -- /dev/vga
> doesn't even exist on FreeBSD).
>
> You may find ktrace helpful in debugging this, as it will allow you to
> trace the system calls in the binary and see where things go wrong.
> Support for Audit, the tracing of security-related events, is currently
> being worked on, but it may be a release or two before it's ready for
> use.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org Principal Research Scientist, McAfee
> Research
>
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe@freebsd.org"
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opshma8u1z0df9kz>