Messages in this thread | | | Date | Tue, 15 Feb 2000 21:24:51 +0100 | From | Andreas Gruenbacher <> | Subject | Re: Capabilities |
| |
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/
| |