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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:21 EST