linux-kernel - Re: [PATCH 3/7] SELinux: Stub in copy-up handling

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3177.1415398128@warthog.procyon.org.uk>
Date:	Fri, 07 Nov 2014 22:08:48 +0000
From:	David Howells <dhowells@...hat.com>
To:	Paul Moore <paul@...l-moore.com>
Cc:	dhowells@...hat.com, linux-unionfs@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] SELinux: Stub in copy-up handling

Paul Moore <paul@...l-moore.com> wrote:

> > +static int selinux_inode_copy_up_xattr(struct dentry *src, struct dentry
> > ...*dst,
> > +				       const char *name, void *value, size_t *size)
> > +{
> > +	if (strcmp(name, XATTR_NAME_SELINUX) == 0)
> > +		return 1; /* Discard */
> 
> I understand that this is just a stub, but I we need to discuss this at some 
> point and I figure better in this patch than elsewhere where it might get 
> lost.
> 
> For the docker, context= mount use case (similar to SELinux/sVirt) dropping 
> the SELinux xattr is probably an okay behavior.  However, I would expect that 
> ultimately this is something we would want to control by policy and/or the 
> presence of a context= label.

The problem is that the label you actually want has already been set and you
have to be careful not to overwrite it.

The other hook (->inode_copy_up) is called first to label the destination
inode - and that has access to the source file also so it can label the
destination with consideration of the attributes on the source.  Normally, the
attributes on the source will be in memory attached to the source inode, I
would imagine.

David
--
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/