jmcmullan@linuxcare.com wrote:
> [...]
> So let me see play with something here (and add the concept
> of a ``Features'' inode, so that we don't have to eat up
> any more space in the superblock):
>
> /dev/hda1 (ext4fs)
> Superblock: Pointer to ``features'' inode
> Features Inode:
> Pointer to Capabilities Inode
> Pointer to ACL Inode
> Pointer to Data Log
> Pointer to Metadata Log
> ...
> Capability List: (id,capability,usage_count) tuples
> Arbitrary Inode: inode->i_capability = pointer to capability id
> [...]
IMO the capabilities table approach (storing a table of capability sets and
indexing it from inodes) is a very bad idea.
Capabilities, Access Control Lists, Auditing, Mandatory Access Control and
Information Labeling are specified in Posix 1003.1e / 1003.2c Draft Standard 17.
DS17 was withdrawn. Nevertheless, implementations of other Unixes are based on
DS17 or earlier drafts.While DS17 is not perfect, a lot of work surely has gone
into Capabilities and ACLs. Most of it actually makes sense.
The specs are publicly available. I guess Casey Schaufler already posted the
link; here it is again: <http://www.guug.de/~winni/posix.1e/download.html>.
As far as capabilities are concerned, it's important at least the user interface
for manipulating ACLs is close to DS17. Having a completely different capability
scheme on Linux makes no sense. Linux tries to be compatible with POSIX and
other Unixes; I see no reason why capabilities should be an exception.
Provided that the user interface is similar to DS17, a capabilities table
just adds complexity that doesn't pay off. The setfcap utility specified in
1003.2c manipulates individual capabilities.
The owner of a file may change the capabilities of a file (provided that he/she
is capable of CAP_SETFCAP). This also affects the per-filesystem capabilities
table. A capability table causes the same trouble when backing up / restoring a
filesystem. Each file and its associated capabilities need to be backed up. Just
backing up the index into the capabilities table doesn't make much sense. When
restoring the file to another filesystem, a capability set corresponding to the
capabilities of the file will probably need to be created ...
I am convinced a fixed set of capabilities is all we need. A limit of 32 may be
too low; 64 seems perfectly reasonable to me. Capabilities are not meant to cure
each and every security problem. Things like protecting /etc/shadow are really
better dealt with by filesystem permissions.
64 capabilities require 3x64 bits for each inode. For future expansion, 3x128
seems a safe limit. Storing 128 more bytes in each inode is beyond limits. Most
files won't use capabilities, so that would be a massive waste of disk space.
I propose to store a pointer to the capabilities of a file in each inode. On
ext2, we already have i_file_acl, which points to the ACL of a file.
Capabilities could be stored at the same location.
One possible implementation:
The ext2 part of the ACLs for Linux project at <acl.bestbits.at> uses i_file_acl
(and i_dir_acl) as a pointer to a disk block that contains the ACL of a file.
The very same disk blocks seem a natural place for storing capabilities. This
adds some trouble in the ACL code (it interferes with the ACL cache), but is
doable.
[Inodes with identical ACLs frequently share an ACL disk block. When an inode
is associated with an ACL, the ACL is looked up in a hash table. If a suitable
ACL disk block is found in the cache, that block is reused; otherwise, a new ACL
disk block is created.]
An alternative for storing capabilities, ACLs, etc. is to implement a mechanism
for storing arbitrary meta information (i.e., attribute lists) for inodes. Irix
XFS supports that. Ext2 has no comparable mechanism, but the i_file_acl block
approach may be good enough.
The SunWorld article ``Controlling Permissions with ACLs'' at
<http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html> and the Linux
ACL project at <http://acl.bestbits.at/> contain some more implementation ideas.
Regards,
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, a.gruenbacher@computer.org
Contact information: http://www.bestbits.at/~agruenba
-
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:30 EST