2015-04-16 13:41:09

by Seung-Woo Kim

[permalink] [raw]
Subject: [RFC PATCH] Security: ignore private inode from security_file_receive

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 <[email protected]>
---

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);
}

--
1.7.4.1


2015-04-16 13:49:40

by Stephen Smalley

[permalink] [raw]
Subject: Re: [RFC PATCH] Security: ignore private inode from security_file_receive

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 <[email protected]>
> ---
>
> 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.

2015-04-16 15:35:52

by Casey Schaufler

[permalink] [raw]
Subject: Re: [RFC PATCH] Security: ignore private inode from security_file_receive

On 4/16/2015 6: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 <[email protected]>
> ---
>
> 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.

If an IS_PRIVATE() check is appropriate, it should be in
smack_file_receive(), not security_file_receive(). Why are you
looking at file->f_path.dentry->d_inode? That's not used in the
Smack access check. You'd want file->f_inode if anything.

Naked-by: Casey Schaufler <[email protected]>

>
> 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);
> }
>

2015-04-17 01:59:47

by Seung-Woo Kim

[permalink] [raw]
Subject: Re: [RFC PATCH] Security: ignore private inode from security_file_receive

Hello,

On 2015년 04월 16일 22:48, Stephen Smalley wrote:
> 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 <[email protected]>
>> ---
>>
>> 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.

Thanks for the suggestion. I will try to do on smack side.

Best Regards,
- Seung-Woo Kim

>
>
>

--
Seung-Woo Kim
Samsung Software R&D Center
--