All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>
Cc: LSM <linux-security-module@vger.kernel.org>,
	LKLM <linux-kernel@vger.kernel.org>,
	SE Linux <selinux@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>,
	John Johansen <john.johansen@canonical.com>,
	Eric Paris <eparis@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Kees Cook <keescook@chromium.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v13 5/9] LSM: Networking component isolation
Date: Wed, 24 Apr 2013 12:09:50 -0700	[thread overview]
Message-ID: <51782DFE.3060808@schaufler-ca.com> (raw)
In-Reply-To: <18474523.4Ny9IacvUQ@sifl>

On 4/24/2013 11:51 AM, Paul Moore wrote:
> On Tuesday, April 23, 2013 09:04:31 AM Casey Schaufler wrote:
>> Subject: [PATCH v13 5/9] LSM: Networking component isolation
>>
>> The NetLabel, XFRM and secmark networking mechanisms are
>> limited to providing security information managed by one
>> LSM. These changes interface the single LSM networking
>> components with the multiple LSM system. Each of the
>> networking components will identify the security ops
>> vector of the LSM that will use it. There are various
>> wrapper functions provided to make this obvious and
>> painless.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ...
>
>> diff --git a/include/net/netlabel.h b/include/net/netlabel.h
>> index 2c95d55..c0cf965 100644
>> --- a/include/net/netlabel.h
>> +++ b/include/net/netlabel.h
>> @@ -406,7 +406,8 @@ int netlbl_secattr_catmap_setrng(struct
>> netlbl_lsm_secattr_catmap *catmap, /*
>>   * LSM protocol operations (NetLabel LSM/kernel API)
>>   */
>> -int netlbl_enabled(void);
>> +int netlbl_register_lsm(struct security_operations *lsmops);
> Nit picky, but I'd prefer "netlbl_lsm_register()".

Not a problem. I will conform to your conventions.

>
>> +int netlbl_enabled(struct security_operations *lsmops);
>>  int netlbl_sock_setattr(struct sock *sk,
>>  			u16 family,
>>  			const struct netlbl_lsm_secattr *secattr);
> ...
>
>> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
>> index 7c94aed..2881d48 100644
>> --- a/net/netlabel/netlabel_kapi.c
>> +++ b/net/netlabel/netlabel_kapi.c
>> @@ -607,23 +607,48 @@ int netlbl_secattr_catmap_setrng(struct
>> netlbl_lsm_secattr_catmap *catmap, * LSM Functions
>>   */
>>
>> +struct security_operations *netlbl_active_lsm;
>> +/**
>> + * netlbl_register_lsm - Reserve the NetLabel subsystem for an LSM
>> + *
>> + * Description:
>> + * To avoid potential conflicting views between LSMs over
>> + * what should go in the network label reserve the Netlabel
>> + * mechanism for use by one LSM. netlbl_enabled will return
>> + * false for all other LSMs.
>> + *
>> + */
> You need a description for the 'lsm' parameter in the comment header above.

Thank you. I missed that.

> Also, this is extremely nit picky but I'd like to see some vertical whitespace 
> between the netlbl_active_lsm declaration and the function header.

White space is easy.

>> +int netlbl_register_lsm(struct security_operations *lsm)
>> +{
>> +	if (lsm == NULL)
>> +		return -EINVAL;
>> +
>> +	if (netlbl_active_lsm == NULL)
>> +		netlbl_active_lsm = lsm;
>> +	else if (netlbl_active_lsm != lsm)
>> +		return -EBUSY;
>> +
>> +	printk(KERN_INFO "NetLabel: Registered LSM \"%s\".\n", lsm->name);
>> +	return 0;
>> +}
>> +
>>  /**
>>   * netlbl_enabled - Determine if the NetLabel subsystem is enabled
>>   *
>>   * Description:
>>   * The LSM can use this function to determine if it should use NetLabel
>> - * security attributes in it's enforcement mechanism.  Currently, NetLabel
>> - * considered to be enabled when it's configuration contains a valid
>> + * security attributes in it's enforcement mechanism.  NetLabel
>> + * considered to be enabled when the LSM making the call is registered
>> + * the netlabel configuration contains a valid setup for
>>   * at least one labeled protocol (i.e. NetLabel can understand incoming
>>   * labeled packets of at least one type); otherwise NetLabel is considered
>>   * be disabled.
>>   *
>>   */
> Same thing, you need a description for the 'lsm' parameter in the comment 
> header above.

I'll add that.

>> -int netlbl_enabled(void)
>> +int netlbl_enabled(struct security_operations *lsm)
>>  {
>> -	/* At some point we probably want to expose this mechanism to the user
>> -	 * as well so that admins can toggle NetLabel regardless of the
>> -	 * configuration */
> It really doesn't matter if you remove that comment or not, but I believe it 
> still applies so long as we do the LSM check first.

OK. I'll leave it alone.

>> +	if (netlbl_active_lsm != lsm)
>> +		return 0;
>>  	return (atomic_read(&netlabel_mgmt_protocount) > 0);
>>  }
> ...
>
>> diff --git a/net/netlabel/netlabel_user.h b/net/netlabel/netlabel_user.h
>> index a6f1705..9990b24 100644
>> --- a/net/netlabel/netlabel_user.h
>> +++ b/net/netlabel/netlabel_user.h
>> @@ -41,6 +41,65 @@
>>
>>  /* NetLabel NETLINK helper functions */
>>
>> +extern struct security_operations *netlbl_active_lsm;
>> +
>> +/**
>> + * netlbl_secid_to_secctx - call the registered secid_to_secctx LSM hook
>> + * @secid - The secid to convert
>> + * @secdata - Where to put the result
>> + * @seclen - Where to put the length of the result
>> + *
>> + * Returns: the result of calling the hook.
>> + */
>> +static inline int netlbl_secid_to_secctx(u32 secid, char **secdata, u32
>> *seclen) +{
>> +	if (netlbl_active_lsm == NULL)
>> +		return -EINVAL;
>> +	return netlbl_active_lsm->secid_to_secctx(secid, secdata, seclen);
>> +}
>> +
>> +/**
>> + * netlbl_release_secctx - call the registered release_secctx LSM hook
>> + * @secdata - The security context to release
>> + * @seclen - The size of the context to release
>> + *
>> + */
>> +static inline void netlbl_release_secctx(char *secdata, u32 seclen)
>> +{
>> +	if (netlbl_active_lsm != NULL)
>> +		netlbl_active_lsm->release_secctx(secdata, seclen);
>> +}
>> +
>> +/**
>> + * netlbl_secctx_to_secid - call the registered seccts_to_secid LSM hook
>> + * @secdata - The security context
>> + * @seclen - The size of the security context
>> + * @secid - Where to put the result
>> + *
>> + * Returns: the result of calling the hook
>> + */
>> +static inline int netlbl_secctx_to_secid(const char *secdata, u32 seclen,
>> +					 u32 *secid)
>> +{
>> +	if (netlbl_active_lsm == NULL) {
>> +		*secid = 0;
>> +		return -EINVAL;
>> +	}
>> +	return netlbl_active_lsm->secctx_to_secid(secdata, seclen, secid);
>> +}
>> +
>> +/**
>> + * netlbl_task_getsecid - call the registered task_getsecid LSM hook
>> + * @p - The task
>> + * @secid - Where to put the secid
>> + *
>> + */
>> +static inline void netlbl_task_getsecid(struct task_struct *p, u32 *secid)
>> +{
>> +	if (netlbl_active_lsm)
>> +		netlbl_active_lsm->task_getsecid(p, secid);
>> +}
> Any particular reason you put all these functions in 'netlabel_user.h'?  I ask 
> because this header is related to the NetLabel netlink interface, with some 
> minor audit stuff tossed in for good measure; it really has nothing to do with 
> the LSM secctx/secid stuff.  I'd probably prefer these functions end up in 
> their own header file for the sake of better organization, maybe 
> 'netlabel_secid.h'?

I can put it anywhere you like. I'd prefer netlabel_lsm.h to netlabel_secid.h,
but if you have a strong preference I'll defer to your conventions.

Thank you.


--
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: Paul Moore <paul@paul-moore.com>
Cc: LSM <linux-security-module@vger.kernel.org>,
	LKLM <linux-kernel@vger.kernel.org>,
	SE Linux <selinux@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>,
	John Johansen <john.johansen@canonical.com>,
	Eric Paris <eparis@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Kees Cook <keescook@chromium.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v13 5/9] LSM: Networking component isolation
Date: Wed, 24 Apr 2013 12:09:50 -0700	[thread overview]
Message-ID: <51782DFE.3060808@schaufler-ca.com> (raw)
In-Reply-To: <18474523.4Ny9IacvUQ@sifl>

On 4/24/2013 11:51 AM, Paul Moore wrote:
> On Tuesday, April 23, 2013 09:04:31 AM Casey Schaufler wrote:
>> Subject: [PATCH v13 5/9] LSM: Networking component isolation
>>
>> The NetLabel, XFRM and secmark networking mechanisms are
>> limited to providing security information managed by one
>> LSM. These changes interface the single LSM networking
>> components with the multiple LSM system. Each of the
>> networking components will identify the security ops
>> vector of the LSM that will use it. There are various
>> wrapper functions provided to make this obvious and
>> painless.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ...
>
>> diff --git a/include/net/netlabel.h b/include/net/netlabel.h
>> index 2c95d55..c0cf965 100644
>> --- a/include/net/netlabel.h
>> +++ b/include/net/netlabel.h
>> @@ -406,7 +406,8 @@ int netlbl_secattr_catmap_setrng(struct
>> netlbl_lsm_secattr_catmap *catmap, /*
>>   * LSM protocol operations (NetLabel LSM/kernel API)
>>   */
>> -int netlbl_enabled(void);
>> +int netlbl_register_lsm(struct security_operations *lsmops);
> Nit picky, but I'd prefer "netlbl_lsm_register()".

Not a problem. I will conform to your conventions.

>
>> +int netlbl_enabled(struct security_operations *lsmops);
>>  int netlbl_sock_setattr(struct sock *sk,
>>  			u16 family,
>>  			const struct netlbl_lsm_secattr *secattr);
> ...
>
>> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
>> index 7c94aed..2881d48 100644
>> --- a/net/netlabel/netlabel_kapi.c
>> +++ b/net/netlabel/netlabel_kapi.c
>> @@ -607,23 +607,48 @@ int netlbl_secattr_catmap_setrng(struct
>> netlbl_lsm_secattr_catmap *catmap, * LSM Functions
>>   */
>>
>> +struct security_operations *netlbl_active_lsm;
>> +/**
>> + * netlbl_register_lsm - Reserve the NetLabel subsystem for an LSM
>> + *
>> + * Description:
>> + * To avoid potential conflicting views between LSMs over
>> + * what should go in the network label reserve the Netlabel
>> + * mechanism for use by one LSM. netlbl_enabled will return
>> + * false for all other LSMs.
>> + *
>> + */
> You need a description for the 'lsm' parameter in the comment header above.

Thank you. I missed that.

> Also, this is extremely nit picky but I'd like to see some vertical whitespace 
> between the netlbl_active_lsm declaration and the function header.

White space is easy.

>> +int netlbl_register_lsm(struct security_operations *lsm)
>> +{
>> +	if (lsm == NULL)
>> +		return -EINVAL;
>> +
>> +	if (netlbl_active_lsm == NULL)
>> +		netlbl_active_lsm = lsm;
>> +	else if (netlbl_active_lsm != lsm)
>> +		return -EBUSY;
>> +
>> +	printk(KERN_INFO "NetLabel: Registered LSM \"%s\".\n", lsm->name);
>> +	return 0;
>> +}
>> +
>>  /**
>>   * netlbl_enabled - Determine if the NetLabel subsystem is enabled
>>   *
>>   * Description:
>>   * The LSM can use this function to determine if it should use NetLabel
>> - * security attributes in it's enforcement mechanism.  Currently, NetLabel
>> - * considered to be enabled when it's configuration contains a valid
>> + * security attributes in it's enforcement mechanism.  NetLabel
>> + * considered to be enabled when the LSM making the call is registered
>> + * the netlabel configuration contains a valid setup for
>>   * at least one labeled protocol (i.e. NetLabel can understand incoming
>>   * labeled packets of at least one type); otherwise NetLabel is considered
>>   * be disabled.
>>   *
>>   */
> Same thing, you need a description for the 'lsm' parameter in the comment 
> header above.

I'll add that.

>> -int netlbl_enabled(void)
>> +int netlbl_enabled(struct security_operations *lsm)
>>  {
>> -	/* At some point we probably want to expose this mechanism to the user
>> -	 * as well so that admins can toggle NetLabel regardless of the
>> -	 * configuration */
> It really doesn't matter if you remove that comment or not, but I believe it 
> still applies so long as we do the LSM check first.

OK. I'll leave it alone.

>> +	if (netlbl_active_lsm != lsm)
>> +		return 0;
>>  	return (atomic_read(&netlabel_mgmt_protocount) > 0);
>>  }
> ...
>
>> diff --git a/net/netlabel/netlabel_user.h b/net/netlabel/netlabel_user.h
>> index a6f1705..9990b24 100644
>> --- a/net/netlabel/netlabel_user.h
>> +++ b/net/netlabel/netlabel_user.h
>> @@ -41,6 +41,65 @@
>>
>>  /* NetLabel NETLINK helper functions */
>>
>> +extern struct security_operations *netlbl_active_lsm;
>> +
>> +/**
>> + * netlbl_secid_to_secctx - call the registered secid_to_secctx LSM hook
>> + * @secid - The secid to convert
>> + * @secdata - Where to put the result
>> + * @seclen - Where to put the length of the result
>> + *
>> + * Returns: the result of calling the hook.
>> + */
>> +static inline int netlbl_secid_to_secctx(u32 secid, char **secdata, u32
>> *seclen) +{
>> +	if (netlbl_active_lsm == NULL)
>> +		return -EINVAL;
>> +	return netlbl_active_lsm->secid_to_secctx(secid, secdata, seclen);
>> +}
>> +
>> +/**
>> + * netlbl_release_secctx - call the registered release_secctx LSM hook
>> + * @secdata - The security context to release
>> + * @seclen - The size of the context to release
>> + *
>> + */
>> +static inline void netlbl_release_secctx(char *secdata, u32 seclen)
>> +{
>> +	if (netlbl_active_lsm != NULL)
>> +		netlbl_active_lsm->release_secctx(secdata, seclen);
>> +}
>> +
>> +/**
>> + * netlbl_secctx_to_secid - call the registered seccts_to_secid LSM hook
>> + * @secdata - The security context
>> + * @seclen - The size of the security context
>> + * @secid - Where to put the result
>> + *
>> + * Returns: the result of calling the hook
>> + */
>> +static inline int netlbl_secctx_to_secid(const char *secdata, u32 seclen,
>> +					 u32 *secid)
>> +{
>> +	if (netlbl_active_lsm == NULL) {
>> +		*secid = 0;
>> +		return -EINVAL;
>> +	}
>> +	return netlbl_active_lsm->secctx_to_secid(secdata, seclen, secid);
>> +}
>> +
>> +/**
>> + * netlbl_task_getsecid - call the registered task_getsecid LSM hook
>> + * @p - The task
>> + * @secid - Where to put the secid
>> + *
>> + */
>> +static inline void netlbl_task_getsecid(struct task_struct *p, u32 *secid)
>> +{
>> +	if (netlbl_active_lsm)
>> +		netlbl_active_lsm->task_getsecid(p, secid);
>> +}
> Any particular reason you put all these functions in 'netlabel_user.h'?  I ask 
> because this header is related to the NetLabel netlink interface, with some 
> minor audit stuff tossed in for good measure; it really has nothing to do with 
> the LSM secctx/secid stuff.  I'd probably prefer these functions end up in 
> their own header file for the sake of better organization, maybe 
> 'netlabel_secid.h'?

I can put it anywhere you like. I'd prefer netlabel_lsm.h to netlabel_secid.h,
but if you have a strong preference I'll defer to your conventions.

Thank you.


  reply	other threads:[~2013-04-24 19:10 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5176ABB7.5080300@schaufler-ca.com>
2013-04-23 16:04 ` [PATCH v13 0/9] LSM: Multiple concurrent LSMs Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-24 18:57   ` Paul Moore
2013-04-24 18:57     ` Paul Moore
2013-04-24 20:22     ` Casey Schaufler
2013-04-24 20:22       ` Casey Schaufler
2013-04-24 21:15       ` Paul Moore
2013-04-24 21:15         ` Paul Moore
2013-04-24 23:00         ` John Johansen
2013-04-25  0:43           ` Casey Schaufler
2013-04-25  0:43             ` Casey Schaufler
2013-04-25 14:16             ` Tetsuo Handa
2013-04-25 15:01             ` Paul Moore
2013-04-25 15:01               ` Paul Moore
2013-04-25 18:09               ` Casey Schaufler
2013-04-25 18:09                 ` Casey Schaufler
2013-04-25 19:14                 ` Paul Moore
2013-04-25 19:14                   ` Paul Moore
2013-04-25 20:21                   ` Casey Schaufler
2013-04-25 20:21                     ` Casey Schaufler
2013-04-25 21:05                     ` Kees Cook
2013-04-25 21:26                     ` Paul Moore
2013-04-25 21:26                       ` Paul Moore
2013-04-23 16:04 ` [PATCH v13 1/9] LSM: Security blob abstraction Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 2/9] LSM: Complete conversion to kill_pid_info_as_cred Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 3/9] LSM: Multiple concurrent secids Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 4/9] LSM: Multiple security context maintenance Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 5/9] LSM: Networking component isolation Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-24 18:51   ` Paul Moore
2013-04-24 18:51     ` Paul Moore
2013-04-24 19:09     ` Casey Schaufler [this message]
2013-04-24 19:09       ` Casey Schaufler
2013-04-24 21:04       ` Paul Moore
2013-04-24 21:04         ` Paul Moore
2013-04-23 16:04 ` [PATCH v13 6/9] LSM: Additional interfaces in /proc/pid/attr Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 7/9] LSM: remove Yama special case stacking Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 20:12   ` Kees Cook
2013-04-23 16:04 ` [PATCH v13 8/9] LSM: Hook list management Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:05 ` [PATCH v13 9/9] LSM: Documentation and cleanup Casey Schaufler
2013-04-23 16:05   ` Casey Schaufler
2013-04-23 19:02   ` Randy Dunlap

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=51782DFE.3060808@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --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.