[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

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.041 / U:0.908 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site