linux-kernel - Re: [PATCH 1/1] fanotify: check permissions when creating file descriptor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140422134044.GE366@quack.suse.cz>
Date:	Tue, 22 Apr 2014 15:40:44 +0200
From:	Jan Kara <jack@...e.cz>
To:	Heinrich Schuchardt <xypron.glpk@....de>
Cc:	Eric Paris <eparis@...hat.com>, Jan Kara <jack@...e.cz>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] fanotify: check permissions when creating file
 descriptor

On Sat 19-04-14 22:53:53, Heinrich Schuchardt wrote:
> When monitoring a directory or a mount with the fanotify API
> the call to fanotify_init checks,
>  * the process has cap_sys_admin capability
> 
> The call to fanotify_mark checks,
>  * the process has read authorization for directory or mount
> 
> A directory or mount may contain files for which the process
> has no read or write authorization.
> Yet when reading from the fanotify file descriptor, structures
> fanotify_event_metadata are returned, which contain a file
> descriptor for these files, and will allow to read or write.
> 
> The patch adds an authorization check for read and write
> permission. In case of missing permission, reading from the
> fanotify file descriptor returns EACCES.
  OK, am I right you are concerned about a situation where fanotify group
descriptor is passed to an unpriviledged process which handles all the
incoming events? I'm asking because the permission checking can be
relatively expensive (think of acls) so we better do it for a reason.
I'd prefer to hear from Eric what the original intention regarding
permissions was...

								Honza
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@....de>
> ---
>  fs/notify/fanotify/fanotify_user.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 4e565c8..5d22a20 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -62,6 +62,8 @@ static int create_fd(struct fsnotify_group *group,
>  {
>  	int client_fd;
>  	struct file *new_file;
> +	int mask;
> +	int ret;
>  
>  	pr_debug("%s: group=%p event=%p\n", __func__, group, event);
>  
> @@ -75,11 +77,19 @@ static int create_fd(struct fsnotify_group *group,
>  	 */
>  	/* it's possible this event was an overflow event.  in that case dentry and mnt
>  	 * are NULL;  That's fine, just don't call dentry open */
> -	if (event->path.dentry && event->path.mnt)
> -		new_file = dentry_open(&event->path,
> -				       group->fanotify_data.f_flags | FMODE_NONOTIFY,
> -				       current_cred());
> -	else
> +	if (event->path.dentry && event->path.mnt) {
> +		/* check permissions before granting access to file */
> +		mask = MAY_READ;
> +		if (group->fanotify_data.f_flags & (O_RDWR | O_WRONLY))
> +			mask |= MAY_WRITE;
> +		ret = inode_permission(event->path.dentry->d_inode, mask);
> +		if (ret)
> +			new_file = ERR_PTR(ret);
> +		else
> +			new_file = dentry_open(&event->path,
> +					       group->fanotify_data.f_flags | FMODE_NONOTIFY,
> +					       current_cred());
> +	} else
>  		new_file = ERR_PTR(-EOVERFLOW);
>  	if (IS_ERR(new_file)) {
>  		/*
> -- 
> 1.9.1
> 
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/