Message-ID: <552FBDB3.4060806@tycho.nsa.gov>
Date: Thu, 16 Apr 2015 09:48:35 -0400
From: Stephen Smalley <sds@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Seung-Woo Kim <sw0312.kim@samsung.com>, james.l.morris@oracle.com,
        serge@hallyn.com, linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org
CC: sumit.semwal@linaro.org, linaro-mm-sig@lists.linaro.org,
        jy0922.shim@samsung.com
Subject: Re: [RFC PATCH] Security: ignore private inode from security_file_receive
References: <1429191656-8866-1-git-send-email-sw0312.kim@samsung.com>
In-Reply-To: <1429191656-8866-1-git-send-email-sw0312.kim@samsung.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1792
Lines: 48

On 04/16/2015 09:40 AM, Seung-Woo Kim wrote:
> The dma-buf fd from anon_inode can be shared across processes, but
> there is no way to set security permission for the fd. So this
> patch fix just to ignore private inode from security_file_receive.
> 
> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> ---
> 
> If security like smack is enabled, the dmabuf fd can not be shared between
> processes via unix domain socket. I am not familiar with security, so I am
> not sure that this kind of patch can be acceptable.
> 
> Is there other option to share dmabuf fd via socket with security check?
> 
> Best Regards,
> - Seung-Woo Kim
> 
> ---
>  security/security.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/security/security.c b/security/security.c
> index 730ac65..c57354c 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -810,6 +810,9 @@ int security_file_send_sigiotask(struct task_struct *tsk,
>  
>  int security_file_receive(struct file *file)
>  {
> +
> +	if (unlikely(IS_PRIVATE(file->f_path.dentry->d_inode)))
> +		return 0;
>  	return security_ops->file_receive(file);
>  }

SELinux handles this internally; see its inode_has_perm() function.
Doing it here would prevent any security module checking at all, even of
the struct file, which SELinux does presently do (selinux_file_receive
calls file_has_perm which applies the fd use check and then calls
inode_has_perm on the inode).  Unless you are saying that the
file->f_security field is also not being set correctly.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/