linux-ext4 - Re: [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize security/acl

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-next>] [day] [month] [year] [list]

Date:	Thu, 10 Apr 2014 05:29:44 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Brian Foster <bfoster@...hat.com>
Cc:	xfs@....sgi.com, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-man@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Al Viro <viro@...iv.linux.org.uk>,
	Andreas Gruenbacher <agruen@...bit.com>
Subject: Re: [PATCH v2 1/2] xfs: fix tmpfile/selinux deadlock and initialize
 security/acl

On Thu, Apr 10, 2014 at 08:19:48AM -0400, Brian Foster wrote:
> Are you saying it doesn't have to initialize security or the default
> acl, or both?

The ACLs for sure.  LSM do run-time access decisions, so they will
probably rely on the security data being initialized.  Given that
O_TMPFILE files aren't publicly available I'm not sure there's a point
in them doing that, though.

LSMs are also affected by the lack of a proper parent I'll discuss for
ACLs below.

> The intent here was to have the case covered where the inode happens to
> be linked back into the namespace since we don't do this work in the
> link path.

That's an interesting one.  O_TMFILE files don't have a real parent
to inherit ACLs from, the pathname passed in just needs to point to
a directory to find the filesystem to create the tmpfile in.  On
the other hand it seem like the extN implementations do inherity the
ACL in this case.

The link into the namespace is irrelavant here as ACL inheritance only
happens on initial create, not at link time.

I also think we'll absolutely need a test case for ACLs+tmpfile to
make sure all filesystems handle it the same way.

> The bulk of the refactoring was with the idea that the inode setup for
> the tmpfile case is generally equivalent for the traditional create
> case. The original version was posted here:
> 
> http://oss.sgi.com/archives/xfs/2014-04/msg00149.html
> 
> ... and it just fixes the deadlock and adds the security initialization.
> I suppose I could still break that out into multiple patches, but that
> aside, is that behavior preferred?

I think just fixing the deadlock and initializing the security is enough
for the first pass.  If you want to do the refactoring on top send it as
a second series on top of the actual fixes.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html