All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Rongqing Li <rongqing.li@windriver.com>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	linux-security-module@vger.kernel.org, sds@tycho.nsa.gov,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.
Date: Tue, 09 Aug 2011 18:35:56 -0700	[thread overview]
Message-ID: <4E41E07C.4080908@schaufler-ca.com> (raw)
In-Reply-To: <4E41DDEB.9040904@windriver.com>

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@windriver.com wrote:
>>>>> From: Roy.Li<rongqing.li@windriver.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.


>
> -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@windriver.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);
>>>>
>>>>
>>>
>>
>>
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: Rongqing Li <rongqing.li@windriver.com>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov,
	linux-security-module@vger.kernel.org, sds@tycho.nsa.gov,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.
Date: Tue, 09 Aug 2011 18:35:56 -0700	[thread overview]
Message-ID: <4E41E07C.4080908@schaufler-ca.com> (raw)
In-Reply-To: <4E41DDEB.9040904@windriver.com>

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@windriver.com wrote:
>>>>> From: Roy.Li<rongqing.li@windriver.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.


>
> -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@windriver.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);
>>>>
>>>>
>>>
>>
>>
>


  reply	other threads:[~2011-08-10  1:36 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09  7:28 [v2 PATCH 0/6] Export the sock's security context to proc rongqing.li
2011-08-09  7:28 ` rongqing.li
2011-08-09  7:28 ` [PATCH 1/6] Security: define security_sk_getsecid rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09 16:13   ` Casey Schaufler
2011-08-09 16:13     ` Casey Schaufler
2011-08-10  0:43     ` Rongqing Li
2011-08-10  0:43       ` Rongqing Li
2011-08-10  0:57       ` Casey Schaufler
2011-08-10  0:57         ` Casey Schaufler
2011-08-10  1:24         ` Rongqing Li
2011-08-10  1:24           ` Rongqing Li
2011-08-10  1:35           ` Casey Schaufler [this message]
2011-08-10  1:35             ` Casey Schaufler
2011-08-10  1:44             ` Rongqing Li
2011-08-10  1:44               ` Rongqing Li
2011-08-10 12:49           ` Stephen Smalley
2011-08-10 12:49             ` Stephen Smalley
2011-08-09  7:28 ` [PATCH 2/6] Define the function to write sock's security context to seq_file rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09  7:28 ` [PATCH 3/6] Export the raw sock's security context to proc rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09  7:28 ` [PATCH 4/6] Export the udp " rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09  7:28 ` [PATCH 5/6] Export the unix " rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09  7:28 ` [PATCH 6/6] Export the tcp " rongqing.li
2011-08-09  7:28   ` rongqing.li
2011-08-09  7:33   ` David Miller
2011-08-09  8:54     ` Rongqing Li
2011-08-09  8:54       ` Rongqing Li

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=4E41E07C.4080908@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rongqing.li@windriver.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.