From: Kentaro Takeda <takedakn@nttdata.co.jp>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Valdis.Kletnieks@vt.edu, Casey Schaufler <casey@schaufler-ca.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, haradats@nttdata.co.jp,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [TOMOYO #9 (2.6.27-rc7-mm1) 1/6] LSM adapter functions.
Date: Mon, 06 Oct 2008 11:19:19 +0900 [thread overview]
Message-ID: <48E975A7.2050000@nttdata.co.jp> (raw)
In-Reply-To: <20081003130937.GF9651@us.ibm.com>
Serge E. Hallyn wrote:
> Why can't you just clear the value during security_inode_foo()?
We need a new hook for clearing the value since security_inode_*()
are not always called after security_path_*() .
> Note I'm seeing this as a way for Tomoyo to temporarily (maybe) work
> around the mis-placement of the security_path_foo() hooks. I don't want
> to add security_path_clear() hooks to "legitimize" the workaround. I'd
> rather Tomoyo and Apparmor folks keep looking for a better way to get
> real DAC-before-MAC.
Hmm, I can understand your opinion. The best way for AppArmor and
TOMOYO is to pass vfsmount to vfs_*() and security_inode_*() . This
approach has no DAC-before-MAC problem. However, it is clearly
opposed by Al because of layering. So, we are going forward
security_path_*() approach, which Al advised us.
Since vfsmount is only available outside vfs_*() (and vfs_*() perform
DAC), we cannot conceive another place now... Where do you think the
right place to introduce security_path_*() hooks is?
Regards,
next prev parent reply other threads:[~2008-10-06 2:19 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
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 [this message]
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=48E975A7.2050000@nttdata.co.jp \
--to=takedakn@nttdata.co.jp \
--cc=Valdis.Kletnieks@vt.edu \
--cc=casey@schaufler-ca.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=serue@us.ibm.com \
--cc=viro@ZenIV.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.