From owner-freebsd-doc@FreeBSD.ORG Mon May 10 16:18:54 2004 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6536516A4CE; Mon, 10 May 2004 16:18:54 -0700 (PDT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 734EE43D39; Mon, 10 May 2004 16:18:52 -0700 (PDT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id DADBF119AD; Tue, 11 May 2004 01:18:50 +0200 (CEST) Date: Tue, 11 May 2004 01:18:50 +0200 From: "Simon L. Nielsen" To: Tom Rhodes Message-ID: <20040510231850.GA844@zaphod.nitro.dk> References: <20040510165153.37575e53@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <20040510165153.37575e53@localhost> User-Agent: Mutt/1.5.6i cc: FreeBSD-doc@FreeBSD.org cc: Robert Watson Subject: Re: [REVIEW REQUEST]: New chapter on MAC (draft) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 23:18:54 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.05.10 16:51:53 -0400, Tom Rhodes wrote: > Hey FreeBSD-doc, >=20 > I've written a new chapter for the handbook on implementing the > MAC features in 5.X. It includes configuration, testing, module > description that augments the section we already have, and shows > examples of the policies. In general: great! :-). I have been looking at the MAC label policies a few times without really understanding how they were suposed to work. It has helped a lot to read this chapter! > I'm not worried about whitespace right now, only correctness in the > information presented, markup, and wording. I have some comments below. I will try to go over it again tomorrow in more detail to give more comments. BTW, there are some parts that are indented, which shouldn't be (not mentioned below since it is more or less whitespace). With security requirements on a rise throughout much of the the world, the demand for a more secure environment has increased. It is from this demand that the TrustedBSD project was founded with nothing more than security in mind. The TrustedBSD project has aimed at developing userland utilities and kern= el interfaces, based on the POSIX.1e standard, and mer= ging it AFAIR POSIX.1e is not really a POSIX standard, but was an draft standard which was never completed (that's my memory anyway, I could very well be wrong). Also, POSIX is also trademark, so &posix;. [snip] After the kernel has been installed, the option may need to be enabled I think it would be good to explain briefly what labels is before you start to explain their use. The MAC portacl Module I have been playing with this policy and I'm actually using it now, so I have fairly good idea how it works. The section contains several inaccuracies... I think the simplest thing is for me to try to rewrite parts of the section to be more accurate. I hope get that done some time tomorrow. MAC Policies with Labeling Features The next few sections will discuss MAC policies which support the labeling features. Please take notice that the improper use of the following information may cause loss of access to the system; aggravation of users; inability to access the features provided by XFree86; and should not s/XFree86/&xfree86;/ be believed to completely secure a system. The MAC framework only promises to augment security but without a good security policy and regulatory security checks, believing the system is totally secure would be irrational if not completely inappropriate. From hereon this chapter will focus on the features of &man.mac.biba.4;, &man.mac.lomac.4;, &man.mac.partition.4;, and &man.mac.mls.4;. For these policies to work correctly several preparations must be made. Preparation for Labeling Policies The following changes should be made to the /etc/login.conf file: An insecure class should be added. The login class of insecure is not required and just used as an example here; different configurations may use another class name. The class of insecure should have the following settings and definitions. insecure:\ :copyright=3D/etc/COPYRIGHT:\ :welcome=3D/etc/motd:\ :setenv=3DMAIL=3D/var/mail/$,BLOCKSIZE=3DK:\ :path=3D~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin :manpath=3D/usr/share/man /usr/local/man:\ :nologin=3D/usr/sbin/nologin:\ :cputime=3D1h30m:\ :datasize=3D8M:\ :vmemoryuse=3D100M:\ :stacksize=3D2M:\ :memorylocked=3D4M:\ :memoryuse=3D8M:\ :filesize=3D8M:\ :coredumpsize=3D8M:\ :openfiles=3D24:\ :maxproc=3D32:\ :priority=3D0:\ :requirehome:\ :passwordtime=3D91d:\ :umask=3D022:\ :ignoretime@:\ :label=3Dpartition/13,mls/5: The cap_mkdb must be run on Manual page entity for cap_mkdb (&man.cap.mkdb.8; AFAIR) login.conf before any of the &man.login.conf.5; users can be switched over to the new class. Set labels for ifconfig interfaces: &prompt.root; ifconfig bge0 maclabel 'biba/hig= h(low-high)' This will set the biba label to high for all incoming and outgoing packets. Ensure that all partitions which MAC labeling will be implemented on support the . We must do this as many of the examples here contain different labels for testing purposes. Review the output from mount command as a precautionary measure. Switch any users who will have the higher security mechanisms enforced over to the new user class. A quick run of pw or vipw &man.pw.8; and &man.vipw.8; should do the trick. The MAC partition Module MAC Process Partition Policy Module name: mac_partition.ko Kernel option: MAC_PARTITION Boot option: mac_partition_load=3D"YES" The &man.mac.partition.4; policy will drop processes into specific partitions based on their MAC label. Think of it as a special type of &man.jail.8;, though that is hardly a worthy comparison. This is one module that should be added to the loader.conf file so that it loads &man.loader.conf.5; and enables the policy during the boot process. The MAC Multi-Level Security Module MAC Multi-Level Security Policy Module name: mac_mls.ko Kernel option: MAC_MLS Boot option: mac_mls_load=3D"YES" The &man.mac.mls.4; policy controls access between subjects and objects in the system by enforcing a strict information flow policy. I think it would be good to have subjects and objects should defined here (or rather, before using them in the above paragraph). In MLS environments, a clearance level is set in each subject or objects label, along with compartments. Since these clearance or sensibility levels can reach numbers greater than six thousand; it would be a daunting task for any system administrator to thoroughly configure each subject or object. Thankfully, three instant labels are already included in this policy. These labels are , and . Since these labels are described in depth in the manual page, they will only get a brief description here: The label contains a low configuration which permits it to be dominated by all other objects. Anything labeled with will have a low clearance level and not permitted to access information of a higher level. In addition, this label will prevent objects of a higher clearance level from writing or passing information on to them. The label should be placed on objects considered to be exempt from the policy. The is the highest level of clearance possible. Objects assigned this label will hold dominance over all over objects in the system; however, they will not permit the leaking of information to objects of a lower class. The following sysctl tunables are available for the configuration of special services and interfaces: is used to enable/disable the MLS policy. will label all &man.pty.4; devices as during Creation. s/Creation/creation/ [snip] Set All Users to Insecure All user accounts that are not root or system users should can now be set to insecure. The following sh script should do the trick: &prompt.root; for x in `awk -F: '($3 >=3D 1001) = && ($3 !=3D 65534) { print $1 }' \ /etc/passwd`; do pw usermod $x -L insecure; done; The cap_mkdb command will need to be run on /etc/master.passwd after this change. Complete the Configuration A contexts file should now be created; the following example was taken from Robert Watson's example policy and should be placed in /etc/policy.contexts. # This is the default BIBA/MLS policy for this syst= em. =2E* 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 simon: If possible I think it would be nice to descript (briefly) what this sample policy is suposed to do. [snip] After establishing a secure environment with MAC, I am no longer able to start XFree86! s/XFree86/&xfree86;/ This could be caused by the MAC policy or by a mislabel in one of the MAC labeling policies. To debug, try the following: Check the error message; if the user in the insecure class then the policy may be the culprit. Try setting the users class back to the default class, rebuild the database with the cap_mkdb command. If this does not alleviate the problem, go to step two. Double check the label policies. Ensure that the policies are set correctly for the user in question, the XFree86 application, and s/XFree86/&xfree86;/ the /dev entries. If neither of these resolve the problem, send the error message and a description of your environment to the TrustedBSD discussion list or the &os; Questions I think there should be some kind of reference where to find the TrustedBSD mailing list. s/&os; Questions mailing list/&a.questions;/; mailing list. --=20 Simon L. Nielsen FreeBSD Documentation Team --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAoA3ah9pcDSc1mlERAsgYAJ4zAwsFMh6MlsHezT20NxZRr4STSQCeOiS8 ON+HLLZrFD6DqCLoD+yZl8I= =9Uwb -----END PGP SIGNATURE----- --ibTvN161/egqYuK8--