Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

[Eric Paris]

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/