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    [from the cache]
©2003-2011 Jasper Spaans