Messages in this thread | | | Subject | Re: [PATCH] vfs: fix IMA lockdep circular locking dependency | From | Eric Paris <> | Date | Wed, 30 May 2012 15:42:47 -0400 |
| |
On Wed, 2012-05-30 at 17:36 +0100, Al Viro wrote:
> The only question is what do we want passed to resulting two hooks. LSM > folks?
Current hook: int security_file_mmap(struct file *file, unsigned long reqprot, unsigned long prot, unsigned long flags, unsigned long addr, unsigned long addr_only)
Obvious easy split: int security_file_mmap(struct file *file, unsigned long reqprot, unsigned long prot, unsigned long flags)
int security_addr_mmap(unsigned long addr)
security_addr_mmap would be used as you described. Which means security_file_mmap() would pretty much only be used in do_mmap_pgoff() (or validate_mmap_request)
file: capabilities: does not use apparmor/smack/selinux: used to get security blobs from file/dentry/inode
reqprot: the PROT_* requested by userspace. prot: the actual PROT_* which will be applied (read-implies-exec is the difference)
capabilities: does not use *prot SMACK: does not use *prot apparmor: only uses prot (not reqprot) SELinux: uses prot or reqprot based on a kernel build/selinuxfs/cmdline value. Fedora/RHEL uses reqprot, not prot. This seems dumb, but it's what we are doing.
These are basically used to check permission to read/write/execute the file based on PROT_READ/PROT_WRITE/PROT_EXECUTE etc. If you move this up we won't have reqprot and prot, we'll only have reqprot. So we would need a helper in the mm code which allow us to easily calculate the read-implies-exec behavior. for apparmor (and less common selinux)
***flags capabilities: does not use SMACK: does not use apparmor: if (!(flags & MAP_PRIVATE)) SELinux: if ((flags & MAP_TYPE) == MAP_SHARED)
So both apparmor and SELinux only use flags to know if PROT_WRITE will actually change the backing file. PROT_WRITE is ignored if MAP_PRIVATE. So this could be a bool called "shared" or the LSMs can just parse the flags. Doesn't matter to me.
| |