[lkml]   [2004]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] capabilites, take 2

    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. 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.021 / U:3.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site