Date: Mon, 4 Dec 2006 18:42:36 GMT From: Todd Miller <millert@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 111053 for review Message-ID: <200612041842.kB4IgafU091855@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=111053 Change 111053 by millert@millert_g5tower on 2006/12/04 18:42:12 Update to reality Affected files ... .. //depot/projects/trustedbsd/sedarwin8/ERRATA#4 edit .. //depot/projects/trustedbsd/sedarwin8/README#5 edit .. //depot/projects/trustedbsd/sedarwin8/darwin/drivers/DeviceAccessControl/README#2 edit Differences ... ==== //depot/projects/trustedbsd/sedarwin8/ERRATA#4 (text+ko) ==== @@ -1,20 +1,21 @@ -Port of TrustedBSD MAC Framework to Darwin 8 +Port of TrustedBSD MAC Framework to Darwin 10.4 SPARTA, Inc 7110 Samuel Morse Drive -Columbia, MD 21046 +Columbia, MD 21046-3401 The following known issues are present in this release: - 52: The fdsec (filesystem) should have labels - The fdesc file system - provides /dev/fd entries on darwin instead of implementing this - within devfs. - 62: Darwin and MAC Framework have no notion of process visibility, unlike FreeBSD. Currently, any process can retrieve information about any other - process. (203 was duplicate) + process. - 96: There is no security for fsoctl, ioctl, sysctl. (225 was duplicate) +111: mach_init needs to run at equal so everything can talk to the + namespace. It has to start its child processes in an mls-specific + manner by performing a mac_set_proc ("mls/low(low-high)") after forking. + The MAC.loginPlugin starts user sessions in a label appropriate for the + user, but system services would still be equal with no automatic way to + change. 130: The Mach error returns from the framework don't always map well. Most framework entry points return bsd errno values, which @@ -22,19 +23,11 @@ framework would return its own private error codes, which could be converted to either type by lookup tables. -135: No MAC access control checks in the fsctl() system call. Darwin - contains a syscall called fsctl() for doing IOCTL-style - operations on a filesystem object via a supplied path. A similar - syscall does not exist in FreeBSD. A generic MAC entry point is - likely needed for this. +141: Some man pages are missing for added system calls. -136: The hfs_ioctl interface allows unchecked ability to modify the - filesystem. hfs_ioctl() allows IOCTL-style commands to be - performed on an HFS filesystem via the fsctl() syscall and - VOP_IOCTL vector. A MAC Framework access control check needs to - be inserted here. - -141: Some man pages are missing for added system calls. +235: "error processing extended attributes: Operation not permitted" is + seen occassionaly during system builds. This can be reproduced when + extended attribute labels change during a copy process. 238: Currently the port label of a label handle is unused. This could (and probably should) be used to implement access control @@ -50,13 +43,50 @@ current work around involves a new ioflag (IO_NOAUTH) which bypasses MAC checks. MAC mediation in vn_rdwr_64() needs to be evaluated. -317: The framework uses the VL_LABELED flag to indicate that a vnode has - been labeled by the framework/policy. This flag is set regardless of - the success/failure of label association/creation. If a policy provides - consistency checking for xattr backed labels and fails to provide a valid - label, the vnode will not have a valid label. Policy and framework - interactions when bad labels is read from the file system needs to be - reviewed. - 321: Additional documentation is needed in mac_policy.h to specify if an entrypoint may sleep. + +339: It's not possible to retrieve SYSV IPC labels. On Panther, there was + no API to access SYSV IPC label information at all, but on Tiger there + is the ipcs program for System V IPC. We may wish to add externalize + operations for those labels. This does not really affect the security + of the system and SYSV IPC is relatively unused. + +340: We should remove process labels entirely (Note: this does not refer + to user credential labels). They were only (poorly) used by LOMAC, + a policy that we didn't port to Darwin. + +345: mac_policy.h should have additional NULLOK tags. We recently added + support for NULLOK tags in mac_policy.h in support of the automatically + generated mac_test policy module. We should run mac_test for a while, + note the messages, confirm with the source code whether they are + permitted to be NULL, and add tags to the interface spec. This will + quiet the verbose mac_test debugging messages where they aren't correct. + +365: mac_vnode_check_lookup() is called with name cache lock held. + cache_lookup_path() in vfs_cache.c calls mac_vnode_check_lookup() with + the name cache mutex held. This means that any policy module that + calls a vn_* functions that uses the name cache will cause deadlock. + For example, a policy calling vn_getname() will end up sleeping forever. + vn_getpath() is exported from BSDKernel.exports. This restriction + needs to be documented. + +375: Revisit architecture issues to achieve real mediation of ioctls(). + Meaningful mediation of ioctl() will require the policy to decode the + fileproc. The framework should perform this for the policy to avoid code + duplication. In the end, real mediation of ioctls() is quite difficult + as they lack sufficient information to allow useful decisions without a + great deal of decoding. + +378: Need a new entry point to replace mpo_vnode_check_mprotect. For instance, + mprotect() can be used to make a (formerly) non-executable address space + executable. This is especially important when the stack is marked non- + executable. It would be nice to detect a process attempting to make the + heap executable as well but that may be difficult on OSX where you don't + have a real sbrk. + +380: Relabeling during certain vnode check operations + (mpo_vnode_check[read,write,open,access]) is needed. + +401: Suspected VFS race causing crashes with MULTILABEL fdesc. + ==== //depot/projects/trustedbsd/sedarwin8/README#5 (text+ko) ==== @@ -9,7 +9,7 @@ ============ This release includes a port of the TrustedBSD MAC Framework to Apple's -Darwin 8.7 (Mac OS X 10.4.7) operating system, made up of kernel, library, +Darwin 8.8 (Mac OS X 10.4.8) operating system, made up of kernel, library, and user space tool extensions to support flexible policy introduction. In addition, several sample policy modules are present: @@ -44,7 +44,7 @@ appropriate for use in production environments. The following modifications have been made relative to Apple's Darwin -8.7 release: +8.8 release: - Inclusion of a subset of the MAC Framework entry points to provide label support and protection of files, processes, System V @@ -60,6 +60,72 @@ Mach servers. The launchd and notifyd daemons have been modified to use our security-enhanced MiG. +New Features in the 20061130 release +===================================== + - Update to a newer version of Tiger; the vendor source base was + updated to Apple's 10.4.8 release (xnu-792.12.6 for PPC). + + - Update other system components to most recent versions + corresponding to Apple's Mac OS X 10.4.8: + cctools-622.5.1 + diskdev_cmds-332.11.5 + file_cmds-116.10 + kext_tools-65.2.1 + launchd-106.14 + msdosfs-89.13 + pam_modules-17.1 + system_cmds-336.1.5 + + - Install man pages for additional APIs and MAC Framework helper + programs. + + - Add new access control checks: + mpo_vnode_check_truncate + mpo_mount_check_fsctl + mpo_file_check_ioctl (renamed from mpo_check_ioctl) + + - Allow USB and Firewire device access control lists to be read + in from a plist file. Additional information is available in the + Policy Module Writing Guide. + + - Remove mac_enforce toggles from the Framework, they were + inconsistent and mostly unused. + + - Change APIs for some devfs entry points. The first parameter was + always NULL; it was removed from the entry points: + mpo_devfs_label_associate_device + mpo_devfs_label_associate_directory + + - Remove the need for an installed /etc/mac.conf file, the default + was changed so that all labels may be displayed. + + - Rename login context creation entry point to a name that is more + appropriate; mpo_lctx_label_associate became mpo_lctx_notify_create. + + - MAC-specific audit data now uses a zone allocator. + + - Update the build system for the GUI components to permit the use + of Xcode 2.4 or newer. + + - Move labeling association for devfs and fdesc out of filesystem + code. Labeling association is now handled the same way for all + filesystems. + + - Sort the APIs in mac_policy.h and mac_framework.h. + + - Correct a logic reversal bug where the mac_get_file and + mac_set_file APIs should follow symlinks but mac_get_link and + mac_set_link should not. + + - Add call graph generation tools; they are located in the + src/release/tools/cgraph directory. + + - Add experimental fdesc multilabel support. Since these changes + are race prone, they are disabled by default. + + - In addition, a large number of bug fixes and minor enhancements + have been made to improve the overall MAC Framework quality. + New Features in the 20061013 release ===================================== ==== //depot/projects/trustedbsd/sedarwin8/darwin/drivers/DeviceAccessControl/README#2 (text+ko) ==== @@ -7,14 +7,13 @@ must be installed in /System/Library/Extensions and they must be loaded. When a device is attached to the system, the DeviceAccessControl driver calls the mac_device_access policy to determine whether it is an approved device. That -policy implements the mpo_check_device_allowed() entry point. +policy implements the mpo_iokit_check_device() entry point. -The mpo_check_device_allowed() routine is passed the device type (currently +The mpo_iokit_check_device() routine is passed the device type (currently only USB, later also Firewire) and a pointer to and the length of a mac_module_data structure: -int mpo_access_check_device_allowed(int devtype, struct mac_module_data *mdata, - int mdlen); +int mpo_iokit_check_device(char* devtype, struct mac_module_data *mdata); The mac_module_data structure contains a set of key/value pairs corresponding to the characteristics of the device. For example, a USB device will have @@ -24,95 +23,164 @@ function returns 0 (zero), otherwise it returns the error EPERM. The DeviceAccessControl driver reverses the sense of the match, matching those -devices _not_ matched by the mpo_access_check_device_allowed() routine. The +devices _not_ matched by the mpo_iokit_check_device() routine. The I/O kit has been modified to favor a match of the driver over any other. -The mpo_access_check_device_allowed() routine uses a hardcoded list of device -parameters against which it matches passed device parameters. This list as of -this writing is: +The mpo_iokit_check_device() routine matches the passed device +parameters against a list of allowed devices. In the model implementation, +this list is specified as an OSModuleData property list in the Info.plist +associated with the mac_device_access kernel extension. This property list is +picked up by the build from the policies/device_access/Default.plist file. +As of this writing, that list looks like: -static struct allowed_devs devlist[] = { - { MAC_DEVICE_USB, 2, { /* Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "516" } /* 0x0204 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "517" } /* 0x0205 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "523" } /* 0x020b */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "524" } /* 0x020c */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Optical USB Mouse */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "770" } /* 0x0302 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Optical USB Mouse */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "772" } /* 0x0304 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Apple Optical USB Mouse */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 4, "774" } /* 0x0306 */ - } - }, - { MAC_DEVICE_USB, 2, { /* OHCI Root Hub Simulation */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 6, "32773" } /* 0x8005 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Hub in Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 5, "4098" } /* 0x1002 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Hub in Apple Extended USB Keyboard */ - { 9, "VendorID", 5, "1452" }, /* 0x05ac */ - { 12, "ModelNumber", 5, "4099" } /* 0x1003 */ - } - }, - { MAC_DEVICE_USB, 2, { /* Texas Instruments Hub */ - { 9, "VendorID", 5, "1105" }, /* 0x0451 */ - { 12, "ModelNumber", 5, "8262" } /* 0x2046 */ - } - }, - { MAC_DEVICE_USB, 2, { /* MachKey Intl USB KVM Switch */ - { 9, "VendorID", 5, "1778" }, /* 0x06f2 */ - { 12, "ModelNumber", 4, "123" } /* 0x007b */ - } - }, - { MAC_DEVICE_FIREWIRE, 2, { /* Apple laptop. */ - { 9, "VendorID", 5, "2599" }, - { 12, "ModelNumber", 3, "10" } - } - } -}; -static unsigned int devlist_ents = sizeof(devlist) / sizeof(struct allowed_devs); +<key>OSModuleData</key> +<dict> + <key>DeviceAccessList</key> + <array> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>516</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>517</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>523</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>524</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Optical USB Mouse</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>770</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Optical USB Mouse</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>772</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Apple Optical USB Mouse</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>774</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>OHCI Root Hub Simulation</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>32773</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Hub in Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>4098</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Hub in Apple Extended USB Keyboard</string> + <key>VendorID</key> + <string>1452</string> + <key>ModelNumber</key> + <string>4099</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>Texas Instruments Hub</string> + <key>VendorID</key> + <string>1105</string> + <key>ModelNumber</key> + <string>8262</string> + </dict> + <dict> + <key>DeviceType</key> + <string>USB</string> + <key>Name</key> + <string>MachKey Intl USB KVM Switch</string> + <key>VendorID</key> + <string>1778</string> + <key>ModelNumber</key> + <string>123</string> + </dict> + <dict> + <key>DeviceType</key> + <string>FireWire</string> + <key>Name</key> + <string>Apple laptop</string> + <key>VendorID</key> + <string>2599</string> + <key>ModelNumber</key> + <string>10</string> + </dict> + </array> +</dict> -Devices are listed as the device type followed by the number of parameters -for the device, then the list of parameters as key length, key, value length, -value tuples. Note that the key and value lengths include the terminating -ASCII NUL ('\0') of the string given. +The device definitions are specified as an array of dict entries. Each +dict entry specifies one device, giving a set of key/string pairs that +identify it. To add a new device, determine the appropriate parameters and add a new entry -to the list following the illustrated pattern. Also change the 'devlist_ents' -value to match the new length of the devlist array. To determine the -parameters for USB devices, first attach the device and then run the USBProber +to the list following the illustrated pattern. To determine the parameters +for USB devices, first attach the device and then run the USBProber application, which may be found on a system with the Xcode package installed in /Developer/Utilities. The "Device Descriptor" field gives the device vendor ID and product ID, among other things. For Firewire devices, one may run the -IORegistryExploror application in the same location; choose the IOFireWire +IORegistryExplorer application in the same location; choose the IOFireWire service plane and follow the tree to the device in question. If the Xcode package is not installed, one may also determine this information using the command 'ioreg -l', which lists all devices known by the registry. @@ -123,13 +191,24 @@ hub or any other USB or Firewire device. For details of device properties for USB and Firewire, see the references -below. The driver currently understands the following device properties: +below. Each entry must have a "DeviceType" key, which may be one of "USB" or +"FireWire". This determines which type of device the entry matches and +supersedes any other potential match (i.e. a FireWire device will never match +a USB device and vice versa, even if all the other keys match). If a device +entry doesn't have a "DeviceType" key, it will be ignored by the matching code +and will end up matching nothing. + +The driver currently understands the following device properties: For all device types: Key name Description + DeviceType "USB" or "FireWire". REQUIRED. VendorID Vendor identification number. ModelNumber Number identifying the device model itself. + Name A human-readable text string describing the + device. This is ignored by the matching code + and is provided for documentation purposes. For USB: Key name Description
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612041842.kB4IgafU091855>