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>