![]() | |||||||||||||
Messages in this thread |
Stephen Smalley wrote: > On Fri, 2004-05-14 at 08:03, Albert Cahalan wrote: > >>This would be an excellent time to reconsider how capabilities >>are assigned to bits. You're breaking things anyway; you might >>as well do all the breaking at once. I want local-use bits so >>that the print queue management access isn't by magic UID/GID. >>We haven't escaped UID-as-priv if server apps and setuid apps >>are still making UID-based access control decisions. > > > Capabilities are a broken model for privilege management; try RBAC/TE > instead. http://www.securecomputing.com/pdf/secureos.pdf has notes > about the history and comparison of capabilities vs. TE. > > Instead of adding new capability bits, replace capable() calls with LSM > hook calls that offer you finer granularity both in operation and in > object-based decisions, and then use a security module like SELinux to > map that to actual permission checks. SELinux provides a framework for > defining security classes and permissions, including both definitions > used by the kernel and definitions used by userspace policy enforcers > (ala security-enhanced X). > Thanks -- turning brain back on, SELinux is obviously better than any fine-grained capability scheme I can imagine. So unless anyone convinces me you're wrong, I'll stick with just fixing up capabilities to work without making them finer-grained. --Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:03 [W:0.299 / U:0.130 seconds] ©2003-2008 Jasper Spaans | |||||||||||||