> Recent discussion of the capability mechanism has highlighted problems
> that arise from the need to attach capability data to files.
> Has anyone suggested holding capability data for files separately from
> the files themselves?
I assume you mean in meta-data -- Yes at
ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.3/
which I plan to merge my stuff with.
> Proposal:
> * associate separate capability data with files when necessary
> * assume default capabilities where no explicit capabilities are found
Yes when -ENODATA or -ENOSYS I try cooking up some defaults.
> * do capability handling in vfs layer
look at that ftp stuff-- fcaps and libcap etc.
> * 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
Look at the patch there, it currently doesn't define how caps live past
reboots. The fcaps-module stores the caps in separate linked list I
beleive not in dentry. That is temporary until ext3 or whatever I presume.
>
> 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
At best the might be able to lift some extraly impossed restrictions.
Noone can seriously suggest that info in the files can be used to raise
caps.
> * file capabilities are not restricted to ext2fs
> * capability system available for scripts, not just in ELF headers
Especially since such headers can only used to restrict not to gain caps.
> * 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?
You use defaults again.
> * what tools have to be modified or created?
look at the above patch.
>
> 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.
I think that limitations and restrictions are good to be closely
bound with the executable. Enablers should be easy to shake.
> For non-invasive development and testing perhaps Erek Zadok's wrapfs
> could be modified to create a 'capability-wrapfs' loadable kernel
> module.
I'll have to look at that.
> 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
Hopefully soonish you can add
http://www.millenniumproductsllc.com/sjp/
I was hopeing to have merged patch and to decouple the elf from elfcap so
that other binary formats could in theory use the same similar mechanism.
I also am thinking of new way to scan through notes that is extensible.
I guess I had best get cracking.
-- Any caps I mention are *derived* from a withdrawn draft posix document. I've finally "unsoiled" myself;->
- 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/