| 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
| ||
|
Message-ID: <47FC8052.9070409@nttdata.co.jp> Date: Wed, 09 Apr 2008 17:37:38 +0900 From: Toshiharu Harada <haradats@...data.co.jp> To: Paul Moore <paul.moore@...com> CC: 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 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. Finally, the following links are our answers to the Linux Weather Forecast. (http://www.linux-foundation.org/en/Linux_Weather_Forecast/security#TOMOYO_Linux) http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison http://sourceforge.jp/projects/tomoyo/document/fosdem2008.pdf http://sourceforge.jp/projects/tomoyo/document/PacSec2007-handout.pdf Regards, Toshiharu Harada NTT DATA CORPORATION -- 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
Powered by blists - more mailing lists