linux-kernel - Re: [PATCH 1/9] Unionfs: security convert lsm into a static interface fix

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: <20071023090739.GA19758@infradead.org>
Date:	Tue, 23 Oct 2007 10:07:39 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	Christoph Hellwig <hch@...radead.org>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	viro@....linux.org.uk, "Serge E. Hallyn" <serue@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Chris Wright <chrisw@...s-sol.org>,
	James Morris <jmorris@...ei.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Josef 'Jeff' Sipek <jsipek@...sunysb.edu>
Subject: Re: [PATCH 1/9] Unionfs: security convert lsm into a static interface fix

On Mon, Oct 22, 2007 at 08:48:04PM -0400, Erez Zadok wrote:
> Why?  Are you concerned that the security policy may change after a module
> is loaded?

No, it's a matter of proper layering.  We generally don't want modules
like stackabke filesystems to call directly into methods but rather use
proper highlevel VFS helpers to isolate them from details and possible
changes.  The move to out of line security_ helpers just put this on the
radard.

> I can probably get rid of having unionfs call security_inode_permission, by
> calling permission() myself and carefully post-process its return code
> (unionfs needs to "ignore" EROFS initially, to allow copyup to take place).

Sounds fine.

> But security_file_ioctl doesn't have any existing helper I can call.  I can
> introduce a trivial vfs_security_file_ioctl wrapper to security_file_ioctl,
> but what about the already existing *19* exported security_* functions in
> security/security.c?  Do you want to see simple wrappers for all of them?
> It seems redundant to add a one-line wrapper around an already one-line
> function around security_ops->XXX.  Plus, some of the existing exported
> security_* functions are file-system related, others are networking, etc.  So
> we'll need wrappers whose names are prefixed appropriately: vfs_*, net_*,
> etc.

The fix for security_file_ioctl is probably to either not do it at all
or move it the call to security_file_ioctl into vfs_ioctl and get it by
using that helper.  I suspect most other security_ exports should be
avoided similarly.

I also suspect the whole issue of where and how-many times to call LSM
methods for stackable filesystems is a huge can of worms and it might make
sense to talk to the LSM folks about it.
-
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/