[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Capabilities
    Jesse Pollard <> wrote:
    > I'd suggest using an index reference to a table containing multiple
    > capability lists. The set of usable capability lists is limited.
    > Many inodes, but the number of uniqe capability lists would be rather
    > low (20-30 most likely).
    > Using a reference:

    > 1. reduces the impact on an inode (8 bits would allow for 255 different
    > capabilitiy lists - reference 0 represents no list)
    > 2. centralizes control over what capability lists are allowed; multiple
    > inodes would be able to reference the same capability list.
    > 3. allows customization by the security administrator (users would not
    > be able to create arbitrary lists)
    > 4. Allows more capabilities to be added without impact to the inode
    > structure, only the reference table support.

    I don't know about the rest of you, but I think this is the first
    capability-based security implementation that make sense. The `lets
    use a bitmask per inode' scenerio would lead - as many people have argued -
    to a _lowering_ of security, since it _increases_ the security-by-obscurity
    elements in the system. (Ie, you can't easily tell, without scanning
    the system file-by-file, who has what capabilities)

    Now, let's assume you're using Jesse Pollard's proposed system, and
    see if it can do any better on accounting:
    (the names and file formats have been made up so I can absorb blame/flame)

    # cat /proc/sys/fs/caps/summary
    id usage name capability
    0 35 default 0x00000000000000FF
    1 47 root 0x000007F007FFFFFF
    2 2 http 0x0000000007F87601
    5 5 ftp 0x00000000000005FF
    6 0 squid 0x00000F0000FF08FF

    # echo "http 0x0000000007F876FF" >/proc/sys/fs/caps/2

    id Identifier of capability
    usage Inodes with this cap
    name Name of capability list
    capability Capabilty mask

    <ADVOCATE CLIENT="devil">
    Ah - NOW you see where this scheme runs into trouble:

    a) How can I, as a process, drop a single capability from
    my capability mask AND have it reported? /proc/self/caps?

    b) Since (correct me if I'm wrong) inodes are cached from disk,
    doesn't this mean that we only get a summary of _CURRENTLY_CACHED_
    inodes? If so, do we really get an accounting advantage over the
    bitmask per inode scheme?

    SO, it looks like administration of capabilities will be improved, but
    we will probably see little to no improvement on the ``what capabilites
    are currently being used by what executables on my system'' front.


    Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
    412.422.8077 tel, 415.701.0792 fax,
    Linuxcare. Support for the revolution.

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

     \ /
      Last update: 2005-03-22 13:56    [W:0.022 / U:51.628 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site