public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, haradats@nttdata.co.jp,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
Date: Fri, 26 Sep 2008 08:04:09 -0500	[thread overview]
Message-ID: <20080926130409.GA14055@us.ibm.com> (raw)
In-Reply-To: <48DC7553.8040708@nttdata.co.jp>

Quoting Kentaro Takeda (takedakn@nttdata.co.jp):
> 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?

I see.  Good point.

Unfortunately I think that is a shortcoming in the security_path_*
patchset.  Unfortunate bc that is going to be a pain to work out.

But I do think it needs to be worked out in the core code, not in
Tomoyo (and each lsm using security_path_*).  So for starters,
both vfs_mknod and vfs_create do may_create, so just pull that
into the callers.  Now Al or Christoph may yell NO due to the
intended layering (which i'm not clear on), in which case the
solution will be tougher.

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

  reply	other threads:[~2008-09-26 13:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24  9:03 [TOMOYO #9 (2.6.27-rc7-mm1) 0/6] TOMOYO Linux Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions Kentaro Takeda
2008-09-25 16:59   ` Serge E. Hallyn
2008-09-26  5:38     ` Kentaro Takeda
2008-09-26 13:04       ` Serge E. Hallyn [this message]
2008-09-29  4:04         ` Kentaro Takeda
2008-09-30 15:45           ` Serge E. Hallyn
2008-09-30 16:14             ` Stephen Smalley
2008-09-30 16:23               ` Serge E. Hallyn
2008-10-01  8:19                 ` Kentaro Takeda
2008-10-01  2:33             ` Casey Schaufler
2008-10-01  5:05               ` Valdis.Kletnieks
2008-10-01  8:23                 ` Kentaro Takeda
2008-10-01 21:15                   ` Serge E. Hallyn
2008-10-02  5:04                     ` Kentaro Takeda
2008-10-02 13:39                       ` Serge E. Hallyn
2008-10-03  6:37                         ` Kentaro Takeda
2008-10-03 13:09                           ` Serge E. Hallyn
2008-10-06  2:19                             ` Kentaro Takeda
2008-10-06 16:54                               ` Serge E. Hallyn
2008-10-07  6:28                                 ` Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 2/6] Memory and pathname management functions Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 3/6] Common functions for TOMOYO Linux Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 4/6] Domain transition handler Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 5/6] File operation restriction part Kentaro Takeda
2008-09-24  9:03 ` [TOMOYO #9 (2.6.27-rc7-mm1) 6/6] Kconfig and Makefile Kentaro Takeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080926130409.GA14055@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=haradats@nttdata.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=takedakn@nttdata.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox