lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Capabilities
    Date
    Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> 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

    Where:
    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?
    </ADVOCATE>

    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.

    Comments?

    --
    Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
    412.422.8077 tel, 415.701.0792 fax
    jmcmullan@linuxcare.com, http://www.linuxcare.com/
    Linuxcare. Support for the revolution.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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