Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Oct 2002 09:34:03 -0700 (PDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   PERFORCE change 20045 for review
Message-ID:  <200210241634.g9OGY3Lb009861@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=20045

Change 20045 by rwatson@rwatson_tislabs on 2002/10/24 09:33:19

	README updates.  Among other things, note that lukemftpd is
	not considered supported because it doesn't use standard
	context management interfaces, meaning that MAC labels
	will not be set properly.  Also remove a bunch of warnings
	that applied only before the VFS changes, note MAC_DEBUG,
	etc.

Affected files ...

.. //depot/projects/trustedbsd/mac/MACREADME#24 edit

Differences ...

==== //depot/projects/trustedbsd/mac/MACREADME#24 (text+ko) ====

@@ -6,17 +6,13 @@
 
 Add the following to your kernel configuration:
 
-options		MAC
+options		MAC			# Mandatory Access Control
+#options 	MAC_DEBUG		# Might also be useful
 
 Rebuild and reinstall world and kernel.  Make sure that login.conf is
 in sync with that provided in the MAC repository, and that login.conf.db
 is up to date also; this can be done most easily via mergemaster(8).
 
-NOTE: It may be necessary to set 'NO_WERROR=yes' in /etc/make.conf to
-successfully build the kernel, due to some warnings introduced when
-integrating MAC into the VFS name lookup code.  These warnings will
-be resolved prior to 5.0-RELEASE.
-
 There are a variety of MAC modules installed in /boot/kernel following
 an installkernel.  Some must be loaded prior to boot in the loader;
 others may be loaded when needed before or after the boot.  The
@@ -82,11 +78,6 @@
 may be inconsistently enforced.  CODA support is probably in the same
 condition.
 
-Currently, non-FreeBSD ABIs are not fully supported.  This includes
-the Linux compatibility layer, and other related components (SCO, et al).
-They will likely not correctly check MAC operations in all cases that the
-normal FreeBSD ABI code does; the status of the ABIs is improving.
-
 Client-side NFS locking is known to Do The Wrong Thing, for a variety
 of reasons.  Unlike the other components of the kernel NFS client,
 it doesn't use the mount-time credential to authorize out-going RPC
@@ -94,26 +85,17 @@
 FIFO, etc.  (This is now largely fixed due to moving VFS protections
 higher in the stack)
 
+Warning: if you have applications that are involved in setting process
+privileges as a result of user login, or act on behalf of a user,
+and they are not base system applications, they may not properly set
+MAC labels for users when they log in.  As such, before assuming that
+these applications will behave properly, you probably want to send
+a query to trustedbsd-discuss@TrustedBSD.org.  At least one base
+system application is known to work improperly: lukemftpd.
+
 Things not to do with MAC
 -------------------------
 
-Don't enable one of the MAC policies after running with persistent
-per-object labels in extended attributes when the MAC policy wasn't
-compiled into your kernel.  The policy will not have had a chance to
-gate label set requests, and the resulting labels on disk may be
-invalid, resulting in a panic.  Instead, make sure to reinitialize all
-of the "freebsd.mac" attributes to their default (with extattrctl(8))
-before starting them again on the new kernel.  Using the
-security.mac.debug_label_fallback tunable/sysctl will permit the
-MAC framework to ignore certain classes of poorly initialized labels,
-but not all.
-
-Don't downgrade a UFS-based filesystem from multilevel to singlelevel,
-and then back to multilevel without a reboot.  The label cache can
-become inconsistent following a downgrade to singlelevel; this is
-not a problem until you re-upgrade.  Instead, remount the filesystem,
-or reboot.
-
 Don't use netboot without setting the loader.conf setting to indicate
 to Biba which interface is trusted.  Otherwise, the NFS client will
 fail as it cannot send packets via the interface.
@@ -121,7 +103,12 @@
 Don't expect X11 to work with MLS enabled if you try to run X11 at
 mls/low (the default).  This won't work because XFree86 expects to
 be able to map video memory, and by default video memory is labeled
-as mls/high so as to be conservative.
+as mls/high so as to be conservative.  If you want to get X to
+work, you can run X at mls/high (possibly not recommended based on
+your security policy requirements) you can run X with an mls/equal
+label to have it override all MLS protections (not advised), or you
+can label the necessary devices so that they can be accessed by the
+user running X (not advised).
 
 For now, use the MAC modules and not the kernel options to enable
 particular MAC policies.  This is necessary because the modules

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe p4-projects" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210241634.g9OGY3Lb009861>