Has anyone suggested holding capability data for files separately from
the files themselves?
Proposal:
* associate separate capability data with files when necessary
* assume default capabilities where no explicit capabilities are found
* do capability handling in vfs layer
* cache capability data with dentry for subsequent use
* message digest hash to relate explicit capabilities to content of file
* require update of explicit capability data when file is modified or
moved
Advantages:
* the file entry itself is unchanged.
* permission bit usage is unchanged for pre-capability systems
* write access to file does not include write access to its capabilities
* file capabilities are not restricted to ext2fs
* capability system available for scripts, not just in ELF headers
* most files require no explicit capability data
Disadvantages:
* performance hit doing lookup for capability information
* administrative complexity
Questions:
* what happens if explicit capability data has invalid hash?
* what tools have to be modified or created?
Some thoughts:
The capability settings for a system are part of the configuration of
the system. When copying a file from one system to another, you would
probably not want it to carry its capabilities with it. On the other
hand you would want to be able to archive the system's capability
settings.
With time it would become clear what tools should be modified to enable
them to deal with files and capabilities at the same time. In the
meantime it would be possible to introduce capability systems into
existing systems.
For non-invasive development and testing perhaps Erek Zadok's wrapfs
could be modified to create a 'capability-wrapfs' loadable kernel
module.
References:
linux-privs: http://www.kernel.org/pub/linux/libs/security/linux-privs/
wrapfs: http://www.cs.columbia.edu/~ezk/research/software/
capbilities in ELF: http://www.goop.org/~jeremy/caps/
CAPELF hack: http://www.kha0s.org/capelf.html
discussion: http://www.tux.org/htdig/hypermail/search_linux-kernel.html
Regards
Peri
-
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/