linux-kernel - Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

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]

Date:	Mon, 5 Feb 2007 19:02:30 +0000
From:	Christoph Hellwig <hch@...radead.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Christoph Hellwig <hch@...radead.org>, Tony Jones <tonyj@...e.de>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chrisw@...s-sol.org, linux-security-module@...r.kernel.org,
	agruen@...e.de, viro@...iv.linux.org.uk
Subject: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

On Mon, Feb 05, 2007 at 10:58:26AM -0800, Trond Myklebust wrote:
> On Mon, 2007-02-05 at 18:44 +0000, Christoph Hellwig wrote:
> > Just FYI:  Al was very opposed to the idea of passing the vfsmount to
> > the vfs_ helpers, so you should discuss this with him.
> > 
> > Looking at the actual patches I see you're lazy in a lot of places.
> > Please make sure that when you introduce a vfsmount argument somewhere
> > that it is _always_ passed and not just when it's conveniant.  Yes, that's
> > more work, but then again if you're not consistant anyone half-serious
> > will laught at a security model using this infrasturcture.
> 
> nfsd in particular tends to be a bit lazy about passing around vfsmount
> info. Forcing it to do so should not be hard since the vfsmount is
> already cached in the "struct export" (which can be found using the
> filehandle). It will take a bit of re-engineering in order to pass that
> information around inside the nfsd code, though.

I actually have a patch to fix that.  It's part of a bigger series
that's not quite ready, but I hope to finish all of it this month.

> Note also that it might be nice to enforce the vfsmount argument by
> replacing the existing dentry parameters with a struct path instead of
> adding an extra reference to the vfsmount to existing functions.

That definitly sounds like a good idea, independent of whether we want
to pass the vfsmount in more places or not.
-
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/