MAC

[Peter Harmsen]

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 at 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 at fledge.watson.org      Principal Research Scientist, McAfee  
> Research
>
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to  
> "freebsd-questions-unsubscribe at freebsd.org"



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/