linux-kernel - Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.

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:	Fri, 26 Sep 2008 14:38:27 +0900
From:	Kentaro Takeda <takedakn@...data.co.jp>
To:	"Serge E. Hallyn" <serue@...ibm.com>
CC:	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, haradats@...data.co.jp,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.

Serge E. Hallyn wrote:
> > So IMO there is some major badness here in the form of copying all of
> > those functions out of fs/namei.c.  I think we need to discuss
> > case-by-case whether using the functions is appropriate (and hence
> > they should be made non-static in fs/namei.c), or whether the intended
> > goal should be met some other way.  For instance:
Indeed.

To perform DAC before MAC, cloning DAC code (like this patch) or some
modifications against existing kernel code (such as non-static
may_open()) are needed.

This posting is the result of our intention that all changes should
be within security/* . We are now aiming TOMOYO Linux to be merged
without messing up the existing kernel code. (Also we put the code of
singly linked list TOMOYO Linux uses not in include/linux/list.h but
in security/tomoyo/common.h to avoid recomplilation.)

We are ready to remove DAC code in TOMOYO Linux LSM module for now.
(But DAC should be performed before MAC, it's our future work.) Since
DAC is performed after security_path_*() hooks, this approach has no
impact to the semantics of TOMOYO Linux. Is it preferable?

> > likewise...  (except in the case of fifo/sock, devcgroup should not be
> > consulted as I'm not sure it'll handle that properly - have you tested
> > tis with the device cgroup enabled?)
Not tested yet... But I don't think problem occurs.

Regards,

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