public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
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
> 

  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