linux-kernel - 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]

Message-Id: <1207745357.21223.391.camel@moss-spartans.epoch.ncsc.mil>
Date:	Wed, 09 Apr 2008 08:49:17 -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 Wed, 2008-04-09 at 17:37 +0900, Toshiharu Harada wrote:
> On 4/8/2008 12:40 AM, Paul Moore wrote:
> > On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
> >> This file contains modifications against kernel source code
> >> needed to use TOMOYO Linux 1.6.
> >>
> >> Although LSM hooks are provided for performing access control,
> >> TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.
> > 
> > Hello,
> > 
> > I understand your frustration with the existing LSM hooks/API and your 
> > reasoning for abandoning LSM in favor of a new set of hooks, however, I 
> > think this sets a dangerous precedence which could result in an 
> > abundance of security related hooks scattered throughout the kernel.  I 
> > would much rather see the LSM API extended/tweaked to support the needs 
> > of SAKURA and TOMOYO than ignored and duplicated; I suspect several 
> > others will say the same.
> > 
> > You have made good progress with TOMOYO so far and if I can remember 
> > correctly you really only have one hurdle left, the VFS portion.  
> > Please continue to seek a solution to this that fits within the LSM 
> > framework.
> > 
> > Thank you.
> 
> Thank you for your comments and concern.
> 
> I realized that we should have included the reason why we decided to
> post non-LSM version. Let me explain the reason and the history.
> 
> We started developing TOMOYO Linux as original patch sets against
> 2.4 vanilla kernel. We understand the role of LSM, so we ported
> TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
> We kept working to reflect feedbacks from the community and believe
> no critical Nack remains.
> 
> http://lwn.net/Articles/238049/
> http://lwn.net/Articles/246930/
> http://lwn.net/Articles/252652/
> http://lwn.net/Articles/254503/
> http://lwn.net/Articles/258905/
> http://lwn.net/Articles/263179/
> http://lwn.net/Articles/264187/
> http://lwn.net/Articles/276603/
> 
> Still there remains an issue of LSM limitation (vfsmount parameter
> isn’t passed to LSM).
> 
> LWN article 239962 says, "At the 2006 summit, Linus took a clear
> position that the use of pathnames for security policies seemed
> reasonable to him". Current LSM implementation is sufficient for SELinux
> and other label based MACs but not for pathname-based MACs.
> This has been argued in the AppAmor thread for quite a long time.
> Though proposals had been posted by AppArmor and TOMOYO Linux project,
> none has been merged until now.
> 
> We apologize for the confusion we caused in the last posting,
> but we don't want to give up returning our work to the mainline. 
> 
> 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.

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).

-- 
Stephen Smalley
National Security Agency

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