Re: [PATCH 2/2] file capabilities: accomodate 32 bit capabilities
Quoting Suparna Bhattacharya ([EMAIL PROTECTED]): On Thu, May 10, 2007 at 01:01:27PM -0700, Andreas Dilger wrote: On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote: Quoting Andreas Dilger ([EMAIL PROTECTED]): One of the important use cases I can see today is the ability to split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine grained attributes. Sounds plausible, though it suffers from both making capabilities far more cumbersome (i.e. finding the right capability for what you wanted to do) and backward compatibility. Perhaps at that point we should introduce security.capabilityv2 xattrs. A binary can then carry security.capability=CAP_SYS_ADMIN=p, and security.capabilityv2=cap_may_clone_mntns=p. Well, the overhead of each EA is non-trivial (16 bytes/EA) for storing 12 bytes worth of data, so it is probably just better to keep extending the original capability fields as was in the proposal. What we definitely do NOT want to happen is an application that needs priviledged access (e.g. e2fsck, mount) to stop running because the new capabilities _would_ have been granted by the new kernel and are not by the old kernel and STRICTXATTR is used. To me it would seem that having extra capabilities on an old kernel is relatively harmless if the old kernel doesn't know what they are. It's like having a key to a door that you don't know where it is. If we ditch the STRICTXATTR option do the semantics seem sane to you? Seems reasonable. It would simplify the code as well, which is good. This does mean no sanity checking of fcaps, am not sure if that matters, I'm guessing it should be similar to the case for other security attributes. which is to trust the xattr... So here is a new consolidated patch without the STRICTXATTR config option. -serge From: Serge E. Hallyn [EMAIL PROTECTED] Subject: [PATCH] Implement file posix capabilities Implement file posix capabilities. This allows programs to be given a subset of root's powers regardless of who runs them, without having to use setuid and giving the binary all of root's powers. This version works with Kaigai Kohei's userspace tools, found at http://www.kaigai.gr.jp/index.php. For more information on how to use this patch, Chris Friedhoff has posted a nice page at http://www.friedhoff.org/fscaps.html. Changelog: May 14: Remove STRICTXATTR support which could make newer binaries unusable on older kernels, and combine the two patches into one. [recent]: 1. Enable the CONFIG_SECURITY_FS_CAPABILITIES option when CONFIG_SECURITY=n. 2. Rename CONFIG_SECURITY_FS_CAPABILITIES to CONFIG_SECURITY_FILE_CAPABILITIES 3. To accomodate 64-bit caps, specify that capabilities are stored as u32 version; u32 eff0; u32 perm0; u32 inh0; u32 eff1; u32 perm1; u32 inh1; (etc) Nov 27: Incorporate fixes from Andrew Morton (security-introduce-file-caps-tweaks and security-introduce-file-caps-warning-fix) Fix Kconfig dependency. Fix change signaling behavior when file caps are not compiled in. Nov 13: Integrate comments from Alexey: Remove CONFIG_ ifdef from capability.h, and use %zd for printing a size_t. Nov 13: Fix endianness warnings by sparse as suggested by Alexey Dobriyan. Nov 09: Address warnings of unused variables at cap_bprm_set_security when file capabilities are disabled, and simultaneously clean up the code a little, by pulling the new code into a helper function. Nov 08: For pointers to required userspace tools and how to use them, see http://www.friedhoff.org/fscaps.html. Nov 07: Fix the calculation of the highest bit checked in check_cap_sanity(). Nov 07: Allow file caps to be enabled without CONFIG_SECURITY, since capabilities are the default. Hook cap_task_setscheduler when !CONFIG_SECURITY. Move capable(TASK_KILL) to end of cap_task_kill to reduce audit messages. Nov 05: Add secondary calls in selinux/hooks.c to task_setioprio and task_setscheduler so that selinux and capabilities with file cap support can be stacked. Sep 05: As Seth Arnold points out, uid checks are out of place for capability code. Sep 01: Define task_setscheduler, task_setioprio, cap_task_kill, and task_setnice to make sure a user cannot affect a process in which they called a program with some fscaps. One remaining question is the note under task_setscheduler: are we ok with CAP_SYS_NICE being sufficient to confine a process to a cpuset? It is a semantic change, as without fsccaps, attach_task doesn't
Re: [PATCH 2/2] file capabilities: accomodate 32 bit capabilities
On Thu, May 10, 2007 at 01:01:27PM -0700, Andreas Dilger wrote: On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote: Quoting Andreas Dilger ([EMAIL PROTECTED]): One of the important use cases I can see today is the ability to split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine grained attributes. Sounds plausible, though it suffers from both making capabilities far more cumbersome (i.e. finding the right capability for what you wanted to do) and backward compatibility. Perhaps at that point we should introduce security.capabilityv2 xattrs. A binary can then carry security.capability=CAP_SYS_ADMIN=p, and security.capabilityv2=cap_may_clone_mntns=p. Well, the overhead of each EA is non-trivial (16 bytes/EA) for storing 12 bytes worth of data, so it is probably just better to keep extending the original capability fields as was in the proposal. What we definitely do NOT want to happen is an application that needs priviledged access (e.g. e2fsck, mount) to stop running because the new capabilities _would_ have been granted by the new kernel and are not by the old kernel and STRICTXATTR is used. To me it would seem that having extra capabilities on an old kernel is relatively harmless if the old kernel doesn't know what they are. It's like having a key to a door that you don't know where it is. If we ditch the STRICTXATTR option do the semantics seem sane to you? Seems reasonable. It would simplify the code as well, which is good. This does mean no sanity checking of fcaps, am not sure if that matters, I'm guessing it should be similar to the case for other security attributes. Regards Suparna Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] file capabilities: accomodate 32 bit capabilities
On May 08, 2007 16:49 -0500, Serge E. Hallyn wrote: Quoting Andreas Dilger ([EMAIL PROTECTED]): One of the important use cases I can see today is the ability to split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine grained attributes. Sounds plausible, though it suffers from both making capabilities far more cumbersome (i.e. finding the right capability for what you wanted to do) and backward compatibility. Perhaps at that point we should introduce security.capabilityv2 xattrs. A binary can then carry security.capability=CAP_SYS_ADMIN=p, and security.capabilityv2=cap_may_clone_mntns=p. Well, the overhead of each EA is non-trivial (16 bytes/EA) for storing 12 bytes worth of data, so it is probably just better to keep extending the original capability fields as was in the proposal. What we definitely do NOT want to happen is an application that needs priviledged access (e.g. e2fsck, mount) to stop running because the new capabilities _would_ have been granted by the new kernel and are not by the old kernel and STRICTXATTR is used. To me it would seem that having extra capabilities on an old kernel is relatively harmless if the old kernel doesn't know what they are. It's like having a key to a door that you don't know where it is. If we ditch the STRICTXATTR option do the semantics seem sane to you? Seems reasonable. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] file capabilities: accomodate 32 bit capabilities
On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote: As the capability set changes and distributions start tagging binaries with capabilities, we would like for running an older kernel to not necessarily make those binaries unusable. (0. Enable the CONFIG_SECURITY_FS_CAPABILITIES option when CONFIG_SECURITY=n.) (1. Rename CONFIG_SECURITY_FS_CAPABILITIES to CONFIG_SECURITY_FILE_CAPABILITIES) 2. Introduce CONFIG_SECURITY_FILE_CAPABILITIES_STRICTXATTR which, when set, prevents loading binaries with capabilities set which the kernel doesn't know about. When not set, such capabilities run, ignoring the unknown caps. 3. To accomodate 64-bit caps, specify that capabilities are stored as u32 version; u32 eff0; u32 perm0; u32 inh0; u32 eff1; u32 perm1; u32 inh1; (etc) Have you considered how such capabilities will be used in the future? One of the important use cases I can see today is the ability to split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine grained attributes. What we definitely do NOT want to happen is an application that needs priviledged access (e.g. e2fsck, mount) to stop running because the new capabilities _would_ have been granted by the new kernel and are not by the old kernel and STRICTXATTR is used. To me it would seem that having extra capabilities on an old kernel is relatively harmless if the old kernel doesn't know what they are. It's like having a key to a door that you don't know where it is. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] file capabilities: accomodate 32 bit capabilities
Quoting Andreas Dilger ([EMAIL PROTECTED]): On May 08, 2007 14:17 -0500, Serge E. Hallyn wrote: As the capability set changes and distributions start tagging binaries with capabilities, we would like for running an older kernel to not necessarily make those binaries unusable. (0. Enable the CONFIG_SECURITY_FS_CAPABILITIES option when CONFIG_SECURITY=n.) (1. Rename CONFIG_SECURITY_FS_CAPABILITIES to CONFIG_SECURITY_FILE_CAPABILITIES) 2. Introduce CONFIG_SECURITY_FILE_CAPABILITIES_STRICTXATTR which, when set, prevents loading binaries with capabilities set which the kernel doesn't know about. When not set, such capabilities run, ignoring the unknown caps. 3. To accomodate 64-bit caps, specify that capabilities are stored as u32 version; u32 eff0; u32 perm0; u32 inh0; u32 eff1; u32 perm1; u32 inh1; (etc) Have you considered how such capabilities will be used in the future? There have been all sorts of suggestions, including very fine-grained breakdowns of existing capabilities as well as capabilities for non-privileged operations. Other candidates for upcoming capabilities will be to satisfy containers/vserver/openvz, where a distinction needs to be made between CAP_DAC_OVERRIDE inside the user namespace, and the global CAP_DAC_OVERRIDE. Although the path i've been pursuing (for which I should really send out the prelim patches I've been sitting on) follow David Howell's and Eric Biederman's suggestions of using the keyrings to store capabilities to other user namespaces. Still new capabilities may be desirable to guard CLONE_NEW_NS etc (rather than CAP_SYS_ADMIN). One of the important use cases I can see today is the ability to split the heavily-overloaded e.g. CAP_SYS_ADMIN into much more fine grained attributes. Sounds plausible, though it suffers from both making capabilities far more cumbersome (i.e. finding the right capability for what you wanted to do) and backward compatibility. Perhaps at that point we should introduce security.capabilityv2 xattrs. A binary can then carry security.capability=CAP_SYS_ADMIN=p, and security.capabilityv2=cap_may_clone_mntns=p. What we definitely do NOT want to happen is an application that needs priviledged access (e.g. e2fsck, mount) to stop running because the new capabilities _would_ have been granted by the new kernel and are not by the old kernel and STRICTXATTR is used. To me it would seem that having extra capabilities on an old kernel is relatively harmless if the old kernel doesn't know what they are. It's like having a key to a door that you don't know where it is. If we ditch the STRICTXATTR option do the semantics seem sane to you? thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
