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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] Principal Research Scientist, McAfee Research
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
