Date: Wed, 8 Mar 2006 21:30:03 GMT From: Todd Miller <millert@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 92987 for review Message-ID: <200603082130.k28LU3kn042025@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=92987 Change 92987 by millert@millert_g5tower on 2006/03/08 21:29:56 Removed fixed bugs. Affected files ... .. //depot/projects/trustedbsd/sedarwin7/ERRATA#4 edit Differences ... ==== //depot/projects/trustedbsd/sedarwin7/ERRATA#4 (text+ko) ==== @@ -21,9 +21,6 @@ PowerBook G4, I see a kernel trap involving IOKit modules within 15 minutes. - 47: Setpmac-spawned processes hang on exit. The MLS policy does not - permit a lower-priority shell to wait(2) on the child process. - 52: The fdsec (filesystem) should have labels - The fdesc file system provides /dev/fd entries on darwin instead of implementing this within devfs. @@ -32,10 +29,6 @@ using extended attributes into a file system that is not using extended attributes, the system will eventually deadlock. - 89: SEDarwin policy rejecting access to /dev/null when it should - not. Is the general_file_write_access macro not being applied - to users? - 91: Users who create and attach new disk images cannot then access them. 93: After reboot, the first time a user logs in, after entering correct @@ -57,7 +50,7 @@ 109: Commands 'ls -Z' and 'ps -Z' fail when no mac config file present. If there is no MAC config file present (no /etc/mac.conf, and $MAC_CONFFILE not set), using the '-Z' flag on - the ls or ps command results in 'Bus error' + the ls or ps command results in 'Bus error'. Fixed in DSEP. 117: The mpo_check_port_relabel entry point does not hold the task label lock. Policies implmenting this entry point should @@ -89,8 +82,9 @@ label handle or text label can use the port label for access control. -239: The SLOT() macro may return NULL in the SEDarwin policy. This - causes a panic in sebsd_externalize_cred_label() when the port - that holds the label has already been destroyed. There appears - to be a missing lock or out of order operation since we should - not be trying to externalized a dead port. +XXX: Threads are not labeled, only tasks. We need to investigate + whether threads deserve their own labels. A task may create + a thread in any task it holds the kernel port for. This means + that the task that holds the control port for a thread may be + different from the task that actually contains the thread. + This may have security implicatons.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603082130.k28LU3kn042025>