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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1338406967.2257.24.camel@localhost>
Date:	Wed, 30 May 2012 15:42:47 -0400
From:	Eric Paris <eparis@...isplace.org>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mimi Zohar <zohar@...ibm.com>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/