Messages in this thread | | | Subject | Re: [PATCH] capabilites, take 2 | From | Stephen Smalley <> | Date | Fri, 14 May 2004 11:21:01 -0400 |
| |
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).
-- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency
- 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/
| |