Date: Tue, 19 Sep 2000 20:51:29 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Subject: Capability patch 0.5.4 (fwd) Message-ID: <Pine.NEB.3.96L.1000919205033.53665A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Figured this might be of interest to people on the freebsd-security side; apologies to those who receive two copies. Any replies to trustedbsd-discuss@TrustedBSD.org if appropriate, please. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Tue, 19 Sep 2000 20:48:31 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: trustedbsd-discuss@TrustedBSD.org Subject: Capability patch 0.5.4 Wow, it even has release notes. Attached below, including build instructions, how to enable capabilities on disk, and a list of changes since the prior revision 0.4. I've committed a number of updates to the base tree in terms of documentation, et al, so you'll need to update to FreeBSD 5.0-CURRENT from around 9/19/2000. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services --- Capability Patch 0.5.4 TO USE Recompile, install world to get userland binary changes. Recompile, install your kernel with FFS_EXTATTR and CAPABILITIES options. Compile cap_test tree. Reboot. Your kernel should now have capability support. You can use sysctl kern.security.capabilities_enabled and sysctl kern.security.suser_enabled To check to see whether capabilities and/or superuser support are currently enabled. kern.security.capabilities_enabled will only be defined if the kernel is compiled to support capabilities. To enable file system support for capabilities, you'll first need to create a backing file for the extended attribute $posix1e.cap. This need only be done once. mkdir /.attribute extattrctl initattr -p / 24 /.attribute/'$posix1e.cap' Add the following line to your /etc/rc.conf, assuming you merged in the new /etc/rc from your source tree: extattr_root="YES" This will automatically enable extended attributes in the root file system based on the name of the file in /.attribute. To manually start the POSIX.1e capabilities attribute without rebooting, run the following: extattrctl start / extattrctl enable / '$posix1e.cap' /.attribute/'$posix1e.cap' If the backing file format or capability structures change, removing and regenerating the attribute file may be required. In the cap_test directory, there is a tool named fsetsomecaps. Running this tool will configure a number of base system binaries. This will only succeed if capabilities are enabled for the file systems containing these binaries, so some caution is required. Name Description ---- ----------- /usr/sbin/traceroute Remove setuid root, replace with CAP_NET_RAW /usr/sbin/traceroute6 Remove setuid root, replace with CAP_NET_RAW /sbin/ping Remove setuid root, replace with CAP_NET_RAW /sbin/ping6 Remove setuid root, replace with CAP_NET_RAW /usr/bin/rlogin Remove setuid root, replace with CAP_NET_BIND_SERVICE /usr/bin/rsh Remove setuid root, replace with CAP_NET_BIND_SERVICE As long as capabilities are enabled both in the kernel (kern.security.capabilities_enabled=1) and file system support is enabled for the file system storing the binary in question, these programs will work. Disabling capabilities will cause them to fail, as they will no longer have the privilege required to execute. Warning: Disabling kern.security.suser_enabled will result in an unusable system, unless you have done a lot more work than that which is described above. This is because CAP_SYS_ADMIN is required to modify sysctl's after suser() has been disabled, and the instructions above do not provide any processes with that capability. CHANGES 0.5.3 -> 0.5.4 o capability.h CAP_* entries redone based on some inconsistencies in their allocation. This means old capability backing files from prior capability patches will no longer behave properly, and must be deleted and recreated. o cap_from_text() and cap_to_text() implemented and documented for libposix1e. The man pages have been committed to the base FreeBSD CVS repository and as such are not included in the patch. o Some man page cleanups, most committed to the base repo and not included in the patch. o cap_test programs rewritten a bit to take advantage of new library calls, but still not posix.2c-happy. Please see the README file in the cap_test-0.5.4.tgz for descriptions of what these utilities do. o /etc/rc, /etc/defaults/rc.conf modified to support automatic starting of capabilities at boot for the root file system. 0.4 -> 0.5.3 o Changed struct cap to use u_int64_t instead of arrays of ints, greatly simplifying the handling of capability objects. This bounds the number of unique capabilities at 64, but that is probably fine in practice. The new capability format is binary-compatible with the old one on x86 hardward, so existing capability EAs should be fine. o Many, many more suser()->cap_check() changes throughout the kernel source code. Pretty much all kern/*, net*/*, and {fs,miscfs}/*/* done. Hardware driver suser()'s generally not done. o New sysctl's kern.security.{capabilities_enabled,suser_enabled} replace kern.suser_enabled, permitting toggling of capabilities and suser support on demand. Don't turn both off at once. kern.suser_permitted remains also, toggling support for the traditional suser() call, but once suser() goes away, it will go away also. o Remove inheritable checking on cap_valid() to better support D17 inheritance properties. o Modify cap_subset() to be more clear, and check all of effective, permitted, and inheritable, rather than just permitted. o Initialize init with all capabilities set permitted|effective, and not inheritable. More consistent with model of booting with capabilities, allowing init to pass capabilities on to /etc/rc and friends as required, rather than tagging them on binaries, increasing post-boot risk. o Conditionalize capability loading from the binary in cap_inherit() on kern.security.capabilities_enabled, as well as CAPABILITIES ifdef. Fix inheritence rules to more closely match D17, as well as move setugid protection stuff out of cap_inherit, using a return of 1 to indicate protection is needed, 0 if not. Change protection rules to protect only for permitted or effective set. o Update cap_check() to use emulate suser(), and to check sysctls as appropriate. Remove cap_check_xxx() and just use cap_check(). o Push lock handling down from syscall interface to cap_get_vp() in most cases. o Implemented cap_get_fd() and cap_set_fd() o As cap_inherit() now returns a value, add protection of process to execve() after cap processing, and now also handle the file handle safety issue dealt with in setugidsafety() which seems to be a horrible hack. o Generally adapt to inclusion of p_can code in base tree, removing a number of differences from the base tree. More than made up for by suser() changes. Adapt capability inclusion in inter-process authorization checking as a result. o Cleanup of capability handling in UFS-derived file systems o Adapt for *_access() -> vaccess() DAC change o There is no POSIX.1e capability for setting the sticky bit on non-directories, and it appears to be a historical curiosity, so simply disallow it. TODO: o Per-fs capability support toggle (mount flag?) o Inherited capability bounds o Rewrite jail() to use inherited capability bounds o Catch the rest of the suser() calls o Verify that all privilege uses suser_used() o CAP_NET_BROADCAST unused, probably should be somewhere. o Allow CAP_MAC_* to break out of jail() o Do capability stuff in exec() in a different order so that execution can fail if appropriate capabilities cannot be acquired due to a bounding set. o CANSIGNAL() still makes an exception in the signal case based on membership in a process session and the signal is SIGCONT. Not sure what to do about this. o Allow sysctl entries to depend on a capability rather than suser o CAP_SYS_ADMIN is a catch-all -- deal with it. o Check SysV IPC protection model and capabaility use o POSIX.2c capability command-line tools o Generalize EA startup so that it can occur for all file systems. o Figure out relationship between kernel-authorized EA writes, immutable flags, etc. Right now, normal authorization checks are only performed for un-privileged users in ufs_extattr_credcheck() and may need fixing. To Unsubscribe: send mail to majordomo@trustedbsd.org with "unsubscribe trustedbsd-discuss" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000919205033.53665A-100000>