From: ebiederm@xmission.com (Eric W. Biederman)
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
john.johansen@canonical.com
Subject: Re: [PATCH 00/23] Removal of binary sysctl support
Date: Thu, 19 Nov 2009 09:49:28 -0800 [thread overview]
Message-ID: <m1ocmy4d7b.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <200911192333.EHB57391.FSQOHOJtMFFLVO@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Thu\, 19 Nov 2009 23\:33\:59 +0900")
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
> But please wait a bit. We need to solve the twist below.
Agreed.
> Indeed. TOMOYO and AppArmor need a hint for prepending "/proc" prefix.
> A simple implementation which adds one bit to task_struct is shown below.
> In this way, not only the file permission checks inside dentry_open()
> but also the directory permission checks inside vfs_path_lookup() can be
> prepended "/proc" prefix. AppArmor might want to prepend "/proc" inside
> vfs_path_lookup().
There don't appear to be any security hooks in vfs_path_lookup().
>
> Regards.
> ----------------------------------------
> [PATCH 1/2] sysctl: Add in_sysctl flag to task_struct.
>
> Pathname based access control prepends "/proc" prefix to the pathname obtained
> by traversing ctl_table tree when binary sysctl is requested.
>
> Now, binary sysctl code was rewritten to use internal vfs mount of /proc but
> currently there is no hint which can give pathname based access control a
> chance to prepend "/proc" prefix.
Actually there is.
> [PATCH 1/2] TOMOYO: prepend /proc prefix for binary sysctl.
>
> The pathname obtained by binary_sysctl() starts with "/sys".
> This patch prepends "/proc" prefix if the pathname was obtained inside
> binary_sysctl() so that TOMOYO checks a pathname which starts with "/proc/sys".
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> security/tomoyo/realpath.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> --- sysctl-2.6.orig/security/tomoyo/realpath.c
> +++ sysctl-2.6/security/tomoyo/realpath.c
> @@ -108,6 +108,14 @@ int tomoyo_realpath_from_path2(struct pa
> spin_unlock(&dcache_lock);
> path_put(&root);
> path_put(&ns_root);
> + /* Prepend "/proc" prefix if binary_sysctl(). */
> + if (!IS_ERR(sp) && current->in_sysctl) {
> + sp -= 5;
> + if (sp >= newname)
> + memcpy(sp, "/proc", 5);
> + else
> + sp = ERR_PTR(-ENOMEM);
> + }
> }
> if (IS_ERR(sp))
> error = PTR_ERR(sp);
Instead of current->in_sysctl we can just look at the path and see if
it is the root of the mount chain and if the fs is proc.
Something like:
diff --git a/security/tomoyo/realpath.c b/security/tomoyo/realpath.c
index 5f2e332..0b55faa 100644
--- a/security/tomoyo/realpath.c
+++ b/security/tomoyo/realpath.c
@@ -108,6 +108,15 @@ int tomoyo_realpath_from_path2(struct path *path, char *newname,
spin_unlock(&dcache_lock);
path_put(&root);
path_put(&ns_root);
+ /* Prepend "/proc" prefix if using internal proc vfs mount. */
+ if (!IS_ERR(sp) && (path->mnt->mnt_parent == path->mnt) &&
+ (strcmp(path->mnt->mnt_sb->s_type->name, "proc") == 0)) {
+ sp -= 5;
+ if (sp >= newname)
+ memcpy(sp, "/proc", 5);
+ else
+ sp = ERR_PTR(-ENOMEM);
+ }
}
if (IS_ERR(sp))
error = PTR_ERR(sp);
Eric
next prev parent reply other threads:[~2009-11-19 17:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-08 12:20 [PATCH 00/23] Removal of binary sysctl support Eric W. Biederman
2009-11-08 13:15 ` Tetsuo Handa
2009-11-08 23:39 ` Eric W. Biederman
2009-11-09 0:12 ` Tetsuo Handa
2009-11-09 0:35 ` Eric W. Biederman
2009-11-18 18:44 ` Eric W. Biederman
2009-11-18 22:04 ` Tetsuo Handa
2009-11-18 22:45 ` Eric W. Biederman
2009-11-19 14:33 ` Tetsuo Handa
2009-11-19 17:49 ` Eric W. Biederman [this message]
2009-11-19 22:17 ` Tetsuo Handa
2009-11-19 22:22 ` Eric W. Biederman
2009-11-19 22:35 ` John Johansen
-- strict thread matches above, loose matches on Subject: below --
2009-11-08 12:16 Eric W. Biederman
2009-11-08 13:06 ` Arnd Bergmann
2009-11-09 3:44 ` Eric W. Biederman
2009-11-08 12:15 Eric W. Biederman
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=m1ocmy4d7b.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.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 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.