netdev - Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

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:	Thu, 10 Apr 2008 08:51:22 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Toshiharu Harada <haradats@...data.co.jp>
Cc:	Paul Moore <paul.moore@...com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Kentaro Takeda <takedakn@...data.co.jp>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-netdev <netdev@...r.kernel.org>
Subject: Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.


On Thu, 2008-04-10 at 14:57 +0900, Toshiharu Harada wrote:
> On 4/9/2008 9:49 PM, Stephen Smalley wrote:
> >> We cordially request LSM changes to pass vfsmount parameters.
> > 
> > Don't cordially request it - submit patches to make it happen.  Or work
> > with others who have been submitting such patches.
> 
> You are (always) right. :)

Definitely not always.

> > There are two options:
> > 1) Submit patches to pass down the vfsmounts to the vfs helpers so that
> > they can be passed to the existing security_inode hooks. -or-
> > 2) Submit patches to add new security hooks to the callers where the
> > vfsmount is already available (some have suggested moving the existing
> > security_inode hooks to the callers, but that would cause problems for
> > SELinux as I've posted elsewhere, so adding new hooks is preferable, and
> > then SELinux can just default to the dummy functions for those new
> > hooks).
> 
> Thank you for your suggestions. I drew a diagram. Is this correct?

I think the text above is self-explanatory; I'm not sure what the
diagram adds.  Also, Matthew Wilcox pointed out a third option that you
ought to consider, and you can look to the example of audit filesystem
watches there, which leverages inotify internally.

If that isn't feasible for some reason, then option (2) should be fairly
straightforward - you just define and insert some new security hooks in
the callers where the vfsmount is already available.

-- 
Stephen Smalley
National Security Agency

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