| 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
| ||
|
Date: Wed, 10 Aug 2011 09:44:34 +0800
From: Rongqing Li <rongqing.li@...driver.com>
To: Casey Schaufler <casey@...aufler-ca.com>
CC: <netdev@...r.kernel.org>, <selinux@...ho.nsa.gov>,
<linux-security-module@...r.kernel.org>, <sds@...ho.nsa.gov>
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.
On 08/10/2011 09:35 AM, Casey Schaufler wrote:
> On 8/9/2011 6:24 PM, Rongqing Li wrote:
>> On 08/10/2011 08:57 AM, Casey Schaufler wrote:
>>> On 8/9/2011 5:43 PM, Rongqing Li wrote:
>>>> On 08/10/2011 12:13 AM, Casey Schaufler wrote:
>>>>> On 8/9/2011 12:28 AM, rongqing.li@...driver.com wrote:
>>>>>> From: Roy.Li<rongqing.li@...driver.com>
>>>>>>
>>>>>> Define security_sk_getsecid to get the security id of a sock.
>>>>>
>>>>> Why are you requesting the secid when you're just going to
>>>>> use it to get the secctx? Why not ask for that directly?
>>>>> Is there ever a case where you only want the secid?
>>>>>
>>>> Hi:
>>>>
>>>> As I know, we have not method to get secctx directly.
>>>
>>> You are defining the method! Ask for what you want!
>>>
>>> The whole notion of secids is a holdover from the bad old
>>> days when SELinux was a user space based enforcement mechanism.
>>> The audit system was implemented when SELinux was the lone LSM
>>> and unfortunately and unnecessarily propagated the use of secids.
>>> If an object has a secid it must also have a secctx. The
>>> interfaces that use secids could just as well use the secctx.
>>> It is wasteful to create a new interface that fetches a secid
>>> just to turn around and ask for the secctx in all cases.
>>>
>>
>> Do you means I should write a method like below
>> security_sk_getsecctx(struct sock *sk, char *secctx, int *len)?
>
> Yes. That is exactly what you should do.
>
>>
>> But secctx only is used to user.
>
> But all you're doing is printing out the secctx. The only
> thing you are doing with the secid is converting it to a
> secctx.
>
>> secid is used to source code to
>> compute and compare the access permission.
>
> That will depend on the LSM involved. You are making a change to
> the LSM, not just SELinux.
>
>>
>> And I do not see the same method like
>> security_task_getsecctx(). but security_task_getsecid() has been
>> implemented in kernel source code.
>
> Have a look at how those interfaces are used.
>
>
Thank you very much.
I will study these interfaces, and hope get your comments when
I send new patches.
Thanks.
>>
>> -Roy
>>
>>
>>>> On the most of time, we get secctx like this.
>>>>
>>>> The below comes from kernel/auditsc.c
>>>>
>>>> void audit_log_task_context(struct audit_buffer *ab)
>>>> {
>>>> char *ctx = NULL;
>>>> unsigned len;
>>>> int error;
>>>> u32 sid;
>>>>
>>>> security_task_getsecid(current,&sid);
>>>> if (!sid)
>>>> return;
>>>>
>>>> error = security_secid_to_secctx(sid,&ctx,&len);
>>>> if (error) {
>>>> if (error != -EINVAL)
>>>> goto error_path;
>>>> return;
>>>> }
>>>>
>>>> audit_log_format(ab, " subj=%s", ctx);
>>>> security_release_secctx(ctx, len);
>>>> return;
>>>>
>>>> error_path:
>>>> audit_panic("error in audit_log_task_context");
>>>> return;
>>>> }
>>>>
>>>>
>>>> -Roy
>>>>
>>>>
>>>>>>
>>>>>> Signed-off-by: Roy.Li<rongqing.li@...driver.com>
>>>>>> ---
>>>>>> include/linux/security.h | 6 ++++++
>>>>>> security/security.c | 6 ++++++
>>>>>> 2 files changed, 12 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/security.h b/include/linux/security.h
>>>>>> index ebd2a53..739ac39 100644
>>>>>> --- a/include/linux/security.h
>>>>>> +++ b/include/linux/security.h
>>>>>> @@ -2560,6 +2560,7 @@ int security_sk_alloc(struct sock *sk, int family, gfp_t priority);
>>>>>> void security_sk_free(struct sock *sk);
>>>>>> void security_sk_clone(const struct sock *sk, struct sock *newsk);
>>>>>> void security_sk_classify_flow(struct sock *sk, struct flowi *fl);
>>>>>> +void security_sk_getsecid(struct sock *sk, u32 *secid);
>>>>>> void security_req_classify_flow(const struct request_sock *req, struct flowi *fl);
>>>>>> void security_sock_graft(struct sock*sk, struct socket *parent);
>>>>>> int security_inet_conn_request(struct sock *sk,
>>>>>> @@ -2701,6 +2702,11 @@ static inline void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
>>>>>> {
>>>>>> }
>>>>>>
>>>>>> +static inline void security_sk_getsecid(struct sock *sk, u32 *secid)
>>>>>> +{
>>>>>> + *secid = 0;
>>>>>> +}
>>>>>> +
>>>>>> static inline void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
>>>>>> {
>>>>>> }
>>>>>> diff --git a/security/security.c b/security/security.c
>>>>>> index 0e4fccf..b0e0825 100644
>>>>>> --- a/security/security.c
>>>>>> +++ b/security/security.c
>>>>>> @@ -1104,6 +1104,12 @@ void security_sk_classify_flow(struct sock *sk, struct flowi *fl)
>>>>>> }
>>>>>> EXPORT_SYMBOL(security_sk_classify_flow);
>>>>>>
>>>>>> +void security_sk_getsecid(struct sock *sk, u32 *secid)
>>>>>> +{
>>>>>> + security_ops->sk_getsecid(sk, secid);
>>>>>> +}
>>>>>> +EXPORT_SYMBOL(security_sk_getsecid);
>>>>>> +
>>>>>> void security_req_classify_flow(const struct request_sock *req, struct flowi *fl)
>>>>>> {
>>>>>> security_ops->req_classify_flow(req, fl);
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Best Reagrds,
Roy | RongQing Li
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists