* Lorenzo Hernandez Garcia-Hierro (lorenzohgh@private) wrote: > Currently it's designed and implemented as follows: > > 1) Each fs or driver provides a table mapping its ioctl commands to > generic ioctl permissions defined by LSM framework, and a capability > if needed. > 2) Each fs or driver looks up the generic ioctl permission from this > table (using a common helper function defined in fs/ioctl_perm.c) and > then calls new security_inode_checkioctl() LSM hook to allow the > security module to check that generic permission prior to performing > ioctl operations. A capability may be assigned to each mapped ioctl > command for later check within the LSM hook. > 3) security_inode_checkioctl() LSM hook checks if a capability parameter > is present. If positive, then calls task_has_capability() to check for > such capability to be granted or denied to the task. If not present, > check is ignored. > 4) Filesystem and driver code can be gradually instrumented in this > manner to provide such controls over an ever larger set of ioctls. Interesting approach. Here are a few issues I see: 1) Ioctls are already a mess, it's not clear this helps that situation. For example, IOC_DIR is already enough to figure read/write, and adding a new table which could get the wrong dir when it's supposedly already encoded just seems to add to the mess. 2) Semantics of privileged vs. unprivileged. For example, in your patch EXT2_IOC_SETFLAGS and EXT2_IOC_SETVERSION may be privileged...depending. In that area, the one case we really care about, setting immutable, is not helped at all. 3) Seperation of declaration of security sensitivity from code, meaning implementation and declaration could drift. 4) Passing capability could mean elimination of capable() call from relevant ioctl code. Tempting, but this obfuscates the security check. But keeping it means it's likely called twice. thanks, -chris
This archive was generated by hypermail 2.1.3 : Thu Nov 10 2005 - 00:05:23 PST