linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Kees Cook <keescook@chromium.org>
Cc: LSM <linux-security-module@vger.kernel.org>,
	"James Morris" <jmorris@namei.org>,
	"SE Linux" <selinux@tycho.nsa.gov>,
	LKLM <linux-kernel@vger.kernel.org>,
	"John Johansen" <john.johansen@canonical.com>,
	"Paul Moore" <paul@paul-moore.com>,
	"Stephen Smalley" <sds@tycho.nsa.gov>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Alexey Dobriyan" <adobriyan@gmail.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Salvatore Mesoraca" <s.mesoraca16@gmail.com>
Subject: Re: [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock
Date: Sun, 23 Sep 2018 10:09:38 -0700	[thread overview]
Message-ID: <b209d4b8-81a5-30aa-f4d1-9372bbb1b842@schaufler-ca.com> (raw)
In-Reply-To: <39457e79-3816-824b-6b4d-89d21b03f9ce@i-love.sakura.ne.jp>

On 9/23/2018 8:59 AM, Tetsuo Handa wrote:
> On 2018/09/23 11:43, Kees Cook wrote:
>>>> I'm excited about getting this landed!
>>> Soon. Real soon. I hope. I would very much like for
>>> someone from the SELinux camp to chime in, especially on
>>> the selinux_is_enabled() removal.
>> Agreed.
>>
> This patchset from Casey lands before the patchset from Kees, doesn't it?

That is up for negotiation. We may end up combining them.

> OK, a few comments (if I didn't overlook something).
>
>   lsm_early_cred()/lsm_early_task() are called from only __init functions.

True.

>   lsm_cred_alloc()/lsm_file_alloc() are called from only security/security.c .

Also true.

>   lsm_early_inode() should be avoided because it is not appropriate to
>   call panic() when lsm_early_inode() is called after __init phase.

You're correct. In fact, lsm_early_inode() isn't needed at all
until multiple inode using modules are supported.

>   Since all free hooks are called when one of init hooks failed, each
>   free hook needs to check whether init hook was called. An example is
>   inode_free_security() in security/selinux/hooks.c (but not addressed in
>   this patch).

I *think* that selinux_inode_free_security() is safe in this
case because the blob will be zeroed, hence isec->list will
be NULL.

>   This patchset might fatally prevent LKM-based LSM modules, for LKM-based
>   LSMs cannot count on lsm_*_alloc() because size for lsm_*_alloc() cannot
>   be updated upon loading LKM-based LSMs.

LKM based security modules will require dynamically sized blobs.
These can be added to the scheme used here. Each blob would get a
header identifying the modules for which it contains data. When an
LKM is registered if has to declare it's blob space requirements
and gets back the offsets. All alloc operations have to put their
marks in the header. All LKM blob users have to check that the blob
they are looking at has the required data.

module_cred(struct cred *cred) {
	return cred->security + module_blob_sizes.lbs_cred;
}

becomes

module_cred(struct cred *cred) {
	if (blob_includes(module_id))
		return cred->security + module_blob_sizes.lbs_cred;
	return NULL;
}

and the calling code needs to accept a NULL return.
Blobs can never get smaller because readjusting the offsets
isn't going to work, so unloading an LKM security module isn't
going to be as complete as you might like. There may be a way
around this if you unload all the LKM modules, but that's a
special case and there may be dragon lurking in the mist.

>  If security_file_free() is called
>   regardless of whether lsm_file_cache is defined, LKM-based LSMs can be
>   loaded using current behavior (apart from the fact that legitimate
>   interface for appending to security_hook_heads is currently missing).
>   How do you plan to handle LKM-based LSMs?

My position all along has been that I don't plan to handle LKM
based LSMs, but that I won't do anything to prevent someone else
from adding them later. I believe that I've done that. Several
designs, including a separate list for dynamically loaded modules
have been proposed. I think some of those would work.

>  include/linux/lsm_hooks.h  |    6 ++----
>  security/security.c        |   31 ++++++-------------------------
>  security/smack/smack_lsm.c |    8 +++++++-
>  3 files changed, 15 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 7e8b32f..8014614 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2095,13 +2095,11 @@ static inline void __init yama_add_hooks(void) { }
>  static inline void loadpin_add_hooks(void) { };
>  #endif
>  
> -extern int lsm_cred_alloc(struct cred *cred, gfp_t gfp);
>  extern int lsm_inode_alloc(struct inode *inode);
>  
>  #ifdef CONFIG_SECURITY
> -void lsm_early_cred(struct cred *cred);
> -void lsm_early_inode(struct inode *inode);
> -void lsm_early_task(struct task_struct *task);
> +void __init lsm_early_cred(struct cred *cred);
> +void __init lsm_early_task(struct task_struct *task);
>  #endif
>  
>  #endif /* ! __LINUX_LSM_HOOKS_H */
> diff --git a/security/security.c b/security/security.c
> index e7c85060..341e8df 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -267,7 +267,7 @@ int unregister_lsm_notifier(struct notifier_block *nb)
>   *
>   * Returns 0, or -ENOMEM if memory can't be allocated.
>   */
> -int lsm_cred_alloc(struct cred *cred, gfp_t gfp)
> +static int lsm_cred_alloc(struct cred *cred, gfp_t gfp)
>  {
>  	if (blob_sizes.lbs_cred == 0) {
>  		cred->security = NULL;
> @@ -286,7 +286,7 @@ int lsm_cred_alloc(struct cred *cred, gfp_t gfp)
>   *
>   * Allocate the cred blob for all the modules if it's not already there
>   */
> -void lsm_early_cred(struct cred *cred)
> +void __init lsm_early_cred(struct cred *cred)
>  {
>  	int rc;
>  
> @@ -344,7 +344,7 @@ void __init security_add_blobs(struct lsm_blob_sizes *needed)
>   *
>   * Returns 0, or -ENOMEM if memory can't be allocated.
>   */
> -int lsm_file_alloc(struct file *file)
> +static int lsm_file_alloc(struct file *file)
>  {
>  	if (!lsm_file_cache) {
>  		file->f_security = NULL;
> @@ -379,25 +379,6 @@ int lsm_inode_alloc(struct inode *inode)
>  }
>  
>  /**
> - * lsm_early_inode - during initialization allocate a composite inode blob
> - * @inode: the inode that needs a blob
> - *
> - * Allocate the inode blob for all the modules if it's not already there
> - */
> -void lsm_early_inode(struct inode *inode)
> -{
> -	int rc;
> -
> -	if (inode == NULL)
> -		panic("%s: NULL inode.\n", __func__);
> -	if (inode->i_security != NULL)
> -		return;
> -	rc = lsm_inode_alloc(inode);
> -	if (rc)
> -		panic("%s: Early inode alloc failed.\n", __func__);
> -}
> -
> -/**
>   * lsm_task_alloc - allocate a composite task blob
>   * @task: the task that needs a blob
>   *
> @@ -466,7 +447,7 @@ int lsm_msg_msg_alloc(struct msg_msg *mp)
>   *
>   * Allocate the task blob for all the modules if it's not already there
>   */
> -void lsm_early_task(struct task_struct *task)
> +void __init lsm_early_task(struct task_struct *task)
>  {
>  	int rc;
>  
> @@ -1202,11 +1183,11 @@ void security_file_free(struct file *file)
>  {
>  	void *blob;
>  
> +	call_void_hook(file_free_security, file);
> +
>  	if (!lsm_file_cache)
>  		return;
>  
> -	call_void_hook(file_free_security, file);
> -

Why does this make sense? If the lsm_file_cache isn't
initialized you can't have allocated any file blobs,
no module can have initialized a file blob, hence there
can be nothing for the module to do.

>  	blob = file->f_security;
>  	file->f_security = NULL;
>  	kmem_cache_free(lsm_file_cache, blob);
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 7843004..b0b4045 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -750,6 +750,13 @@ static int smack_set_mnt_opts(struct super_block *sb,
>  	if (sp->smk_flags & SMK_SB_INITIALIZED)
>  		return 0;
>  
> +	if (inode->i_security == NULL) {
> +		int rc = lsm_inode_alloc(inode);
> +
> +		if (rc)
> +			return rc;
> +	}
> +
>  	if (!smack_privileged(CAP_MAC_ADMIN)) {
>  		/*
>  		 * Unprivileged mounts don't get to specify Smack values.
> @@ -818,7 +825,6 @@ static int smack_set_mnt_opts(struct super_block *sb,
>  	/*
>  	 * Initialize the root inode.
>  	 */
> -	lsm_early_inode(inode);
>  	init_inode_smack(inode, sp->smk_root);
>  
>  	if (transmute) {


  reply	other threads:[~2018-09-23 17:09 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-21 23:59 [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock Casey Schaufler
2018-09-22  0:16 ` [PATCH v4 01/19] procfs: add smack subdir to attrs Casey Schaufler
2018-09-22  0:17 ` [PATCH v4 02/19] Smack: Abstract use of cred security blob Casey Schaufler
2018-09-22  2:44   ` Kees Cook
2018-09-22  0:17 ` [PATCH v4 03/19] SELinux: " Casey Schaufler
2018-09-22  0:17 ` [PATCH v4 04/19] SELinux: Remove cred security blob poisoning Casey Schaufler
2018-09-22  2:43   ` Kees Cook
2018-09-27 22:13   ` James Morris
2018-09-27 22:32     ` Casey Schaufler
2018-09-22  0:17 ` [PATCH v4 05/19] SELinux: Remove unused selinux_is_enabled Casey Schaufler
2018-09-22  2:43   ` Kees Cook
2018-09-22  0:17 ` [PATCH v4 06/19] AppArmor: Abstract use of cred security blob Casey Schaufler
2018-09-22  2:46   ` Kees Cook
2018-09-22  0:18 ` [PATCH v4 07/19] TOMOYO: " Casey Schaufler
2018-09-22  2:47   ` Kees Cook
2018-09-22  0:18 ` [PATCH v4 08/19] Infrastructure management of the " Casey Schaufler
2018-09-22  2:50   ` Kees Cook
2018-09-22  0:18 ` [PATCH v4 09/19] SELinux: Abstract use of file " Casey Schaufler
2018-09-22  0:18 ` [PATCH v4 10/19] Smack: " Casey Schaufler
2018-09-22  2:51   ` Kees Cook
2018-09-22  0:19 ` [PATCH v4 11/19] LSM: Infrastructure management of the file security Casey Schaufler
2018-09-22  2:53   ` Kees Cook
2018-09-22  0:19 ` [PATCH v4 12/19] SELinux: Abstract use of inode security blob Casey Schaufler
2018-09-22  0:19 ` [PATCH v4 13/19] Smack: " Casey Schaufler
2018-09-22  0:19 ` [PATCH v4 14/19] LSM: Infrastructure management of the inode security Casey Schaufler
2018-09-22  2:55   ` Kees Cook
2018-10-03 18:13     ` James Morris
2018-10-04  4:49       ` Casey Schaufler
2018-09-22  0:19 ` [PATCH v4 15/19] LSM: Infrastructure management of the task security Casey Schaufler
2018-09-22  2:56   ` Kees Cook
2018-09-22  0:19 ` [PATCH v4 16/19] SELinux: Abstract use of ipc security blobs Casey Schaufler
2018-09-22  2:56   ` Kees Cook
2018-09-22  0:19 ` [PATCH v4 17/19] Smack: " Casey Schaufler
2018-09-22  2:57   ` Kees Cook
2018-09-22  0:20 ` [PATCH v4 18/19] LSM: Infrastructure management of the ipc security blob Casey Schaufler
2018-09-22  2:58   ` Kees Cook
2018-09-22  0:20 ` [PATCH v4 19/19] LSM: Blob sharing support for S.A.R.A and LandLock Casey Schaufler
2018-09-22  0:22 ` [PATCH v4 09/19] SELinux: Abstract use of file security blob Casey Schaufler
2018-09-22  3:02 ` [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock Kees Cook
2018-09-22 16:38   ` Casey Schaufler
2018-09-23  2:43     ` Kees Cook
2018-09-23 15:59       ` Tetsuo Handa
2018-09-23 17:09         ` Casey Schaufler [this message]
2018-09-24  1:53           ` Tetsuo Handa
2018-09-24 17:16             ` Casey Schaufler
2018-09-24 17:53               ` Tetsuo Handa
2018-09-24 20:33                 ` Casey Schaufler
2018-09-24 15:01           ` Stephen Smalley
2018-09-24 16:15             ` Casey Schaufler
2018-09-24 17:22               ` Tetsuo Handa
2018-10-01 17:58           ` James Morris
2018-09-26 21:57 ` [PATCH v4 20/19] LSM: Correct file blob free empty blob check Casey Schaufler
2018-10-01 20:29   ` Kees Cook
2018-09-26 21:57 ` [PATCH 21/19] LSM: Cleanup and fixes from Tetsuo Handa Casey Schaufler
2018-10-01 21:48   ` Kees Cook
2018-10-12 20:07     ` Kees Cook

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=b209d4b8-81a5-30aa-f4d1-9372bbb1b842@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=adobriyan@gmail.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=paul@paul-moore.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=s.mesoraca16@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).