From: Vivek Goyal <vgoyal@redhat.com>
To: "Michael Weiß" <michael.weiss@aisec.fraunhofer.de>
Cc: miklos@szeredi.hu, linux-unionfs@vger.kernel.org
Subject: Re: [PATCH] ovl: Introduce mount option hide_paths
Date: Thu, 11 Apr 2019 16:11:31 -0400 [thread overview]
Message-ID: <20190411201131.GA23000@redhat.com> (raw)
In-Reply-To: <20190410100150.13939-1-michael.weiss@aisec.fraunhofer.de>
Hi Michael,
Just curious, is this isue specific to overlayfs. What about other
file systems. They will give device path info. I am wondering what
will happen to bind mounts.
Vivek
On Wed, Apr 10, 2019 at 12:01:51PM +0200, Michael Wei� wrote:
> Currently, if an overlayfs is mounted, the path names of lowerdir,
> upperdir and workdir are visible in /proc/<pid>/mounts and so on.
>
> However, in namespaced environments, e.g., lxc or docker, the
> path names leak information of the host's directory structure.
>
> With the new mount option 'hide_paths' this information is not shown
> in proc anymore.
>
> Signed-off-by: Michael Wei� <michael.weiss@aisec.fraunhofer.de>
> ---
>
> Hi Folks,
>
> while implementing some os level virtulization framework using overlayfs
> to craft my rootfs for a container, I realized that the fsoptions
> shown in /proc/<pid>/mounts remain the same after a move mount.
> Thus, in the new mount namespace of the container the former paths
> of the root namespace used to craft the rootfs are leaked to the
> container.
>
> I think this is also useful for those Docker or LXC guys to allow using
> their container runtimes in more security related use cases.
>
> Cheers,
> Michael
>
> Documentation/filesystems/overlayfs.txt | 16 ++++++++++++++++
> fs/overlayfs/ovl_entry.h | 1 +
> fs/overlayfs/super.c | 19 ++++++++++++++-----
> 3 files changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt
> index eef7d9d259e8..ec615e8932a8 100644
> --- a/Documentation/filesystems/overlayfs.txt
> +++ b/Documentation/filesystems/overlayfs.txt
> @@ -469,6 +469,22 @@ verified on mount time to check that upper file handles are not stale.
> This verification may cause significant overhead in some cases.
>
>
> +Hiding path information
> +-----------------------
> +
> +In namespace environments, it can be required to hide information
> +about the host's overlay structure for a mountpoint.
> +
> +E.g., if a rootfs is build by overlaying several read-only and a writable
> +path and a move mount to the mountpoint is performed later for a mount
> +namespace, then the options for lowerdir,upperdir and workdir includes the
> +original path names. After a chroot these paths are even not existing anymore.
> +
> +However, /proc/<pid>/mounts will show the obsolete information in that case.
> +To avoid this information leakage, the mount option "hide_paths" can be used to
> +remove the path related options from the relevant proc files.
> +
> +
> Testsuite
> ---------
>
> diff --git a/fs/overlayfs/ovl_entry.h b/fs/overlayfs/ovl_entry.h
> index ec237035333a..00abcef6fb30 100644
> --- a/fs/overlayfs/ovl_entry.h
> +++ b/fs/overlayfs/ovl_entry.h
> @@ -20,6 +20,7 @@ struct ovl_config {
> bool nfs_export;
> int xino;
> bool metacopy;
> + bool hide_paths;
> };
>
> struct ovl_sb {
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index 0116735cc321..195a84dbbd94 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -24,7 +24,6 @@ MODULE_AUTHOR("Miklos Szeredi <miklos@szeredi.hu>");
> MODULE_DESCRIPTION("Overlay filesystem");
> MODULE_LICENSE("GPL");
>
> -
> struct ovl_dir_cache;
>
> #define OVL_MAX_STACK 500
> @@ -343,10 +342,14 @@ static int ovl_show_options(struct seq_file *m, struct dentry *dentry)
> struct super_block *sb = dentry->d_sb;
> struct ovl_fs *ofs = sb->s_fs_info;
>
> - seq_show_option(m, "lowerdir", ofs->config.lowerdir);
> - if (ofs->config.upperdir) {
> - seq_show_option(m, "upperdir", ofs->config.upperdir);
> - seq_show_option(m, "workdir", ofs->config.workdir);
> + if (ofs->config.hide_paths) {
> + seq_puts(m, ",hide_paths");
> + } else {
> + seq_show_option(m, "lowerdir", ofs->config.lowerdir);
> + if (ofs->config.upperdir) {
> + seq_show_option(m, "upperdir", ofs->config.upperdir);
> + seq_show_option(m, "workdir", ofs->config.workdir);
> + }
> }
> if (ofs->config.default_permissions)
> seq_puts(m, ",default_permissions");
> @@ -401,6 +404,7 @@ enum {
> OPT_XINO_AUTO,
> OPT_METACOPY_ON,
> OPT_METACOPY_OFF,
> + OPT_HIDE_PATHS,
> OPT_ERR,
> };
>
> @@ -419,6 +423,7 @@ static const match_table_t ovl_tokens = {
> {OPT_XINO_AUTO, "xino=auto"},
> {OPT_METACOPY_ON, "metacopy=on"},
> {OPT_METACOPY_OFF, "metacopy=off"},
> + {OPT_HIDE_PATHS, "hide_paths"},
> {OPT_ERR, NULL}
> };
>
> @@ -557,6 +562,10 @@ static int ovl_parse_opt(char *opt, struct ovl_config *config)
> config->metacopy = false;
> break;
>
> + case OPT_HIDE_PATHS:
> + config->hide_paths = true;
> + break;
> +
> default:
> pr_err("overlayfs: unrecognized mount option \"%s\" or missing value\n", p);
> return -EINVAL;
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-04-11 20:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 10:01 [PATCH] ovl: Introduce mount option hide_paths Michael Weiß
2019-04-11 20:11 ` Vivek Goyal [this message]
2019-04-12 7:44 ` Michael Weiß
2019-04-12 11:25 ` Amir Goldstein
2019-04-12 13:48 ` Michael Weiß
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=20190411201131.GA23000@redhat.com \
--to=vgoyal@redhat.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=michael.weiss@aisec.fraunhofer.de \
--cc=miklos@szeredi.hu \
/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