linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Wiklander <jens.wiklander@linaro.org>
To: Elvira Khabirova <e.khabirova@omprussia.ru>
Cc: op-tee@lists.trustedfirmware.org, linux-kernel@vger.kernel.org,
	vesa.jaaskelainen@vaisala.com, s.shtylyov@omprussia.ru,
	k.karasev@omprussia.ru
Subject: Re: [RFC PATCH] tee: add support for application-based session login methods
Date: Wed, 30 Sep 2020 08:11:53 +0200	[thread overview]
Message-ID: <20200930061153.GA738306@jade> (raw)
In-Reply-To: <20200930050101.034762a7@akathisia>

On Wed, Sep 30, 2020 at 05:01:01AM +0300, Elvira Khabirova wrote:
> On Mon, 28 Sep 2020 15:43:47 +0200
> Jens Wiklander <jens.wiklander@linaro.org> wrote:
> 
> > Hi Elvira,
> > 
> > On Thu, Sep 17, 2020 at 06:38:03PM +0300, Elvira Khabirova wrote:
> > > GP TEE Client API in addition to login methods already supported
> > > in the kernel also defines several application-based methods:
> > > TEEC_LOGIN_APPLICATION, TEEC_LOGIN_USER_APPLICATION, and
> > > TEEC_LOGIN_GROUP_APPLICATION.
> > > 
> > > It specifies credentials generated for TEEC_LOGIN_APPLICATION as only
> > > depending on the identity of the program, being persistent within one
> > > implementation, across multiple invocations of the application
> > > and across power cycles, enabling them to be used to disambiguate
> > > persistent storage. The exact nature is REE-specific.
> > > 
> > > As the exact method of generating application identifier strings may
> > > vary between vendors, setups and installations, add two suggested
> > > methods and an exact framework for vendors to extend upon.
> > > 
> > > Signed-off-by: Elvira Khabirova <e.khabirova@omprussia.ru>
> > > ---
> > >  drivers/tee/Kconfig    |  29 +++++++++
> > >  drivers/tee/tee_core.c | 136 ++++++++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 164 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> > > index e99d840c2511..4cd6e0d2aad5 100644
> > > --- a/drivers/tee/Kconfig
> > > +++ b/drivers/tee/Kconfig
> > > @@ -11,6 +11,35 @@ config TEE
> > >  	  This implements a generic interface towards a Trusted Execution
> > >  	  Environment (TEE).
> > >  
> > > +choice
> > > +	prompt "Application ID for client UUID"
> > > +	depends on TEE
> > > +	default TEE_APPID_PATH
> > > +	help
> > > +	  This option allows to choose which method will be used to generate
> > > +	  application identifiers for client UUID generation when login methods
> > > +	  TEE_LOGIN_APPLICATION, TEE_LOGIN_USER_APPLICATION
> > > +	  and TEE_LOGIN_GROUP_APPLICATION are used.
> > > +	  Please be mindful of the security of each method in your particular
> > > +	  installation.
> > > +
> > > +	config TEE_APPID_PATH
> > > +		bool "Path-based application ID"
> > > +		help
> > > +		  Use the executable's path as an application ID.
> > > +
> > > +	config TEE_APPID_SECURITY
> > > +		bool "Security extended attribute based application ID"
> > > +		help
> > > +		  Use the executable's security extended attribute as an application ID.
> > > +endchoice
> > > +
> > > +config TEE_APPID_SECURITY_XATTR
> > > +	string "Security extended attribute to use for application ID"
> > > +	depends on TEE_APPID_SECURITY
> > > +	help
> > > +	  Attribute to be used as an application ID (with the security prefix removed).
> > > +
> > >  if TEE
> > >  
> > >  menu "TEE drivers"
> > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > index 64637e09a095..19c965dd212b 100644
> > > --- a/drivers/tee/tee_core.c
> > > +++ b/drivers/tee/tee_core.c
> > > @@ -7,8 +7,10 @@
> > >  
> > >  #include <linux/cdev.h>
> > >  #include <linux/cred.h>
> > > +#include <linux/file.h>
> > >  #include <linux/fs.h>
> > >  #include <linux/idr.h>
> > > +#include <linux/mm.h>
> > >  #include <linux/module.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/tee_drv.h>
> > > @@ -17,11 +19,15 @@
> > >  #include <crypto/sha.h>
> > >  #include "tee_private.h"
> > >  
> > > +#ifdef CONFIG_TEE_APPID_SECURITY
> > No need for the ifdef, just inlude the file unconditionally above.
> > 
> > > +#include <linux/security.h>
> > > +#endif
> > > +
> > >  #define TEE_NUM_DEVICES	32
> > >  
> > >  #define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x))
> > >  
> > > -#define TEE_UUID_NS_NAME_SIZE	128
> > > +#define TEE_UUID_NS_NAME_SIZE	PATH_MAX
> > >  
> > >  /*
> > >   * TEE Client UUID name space identifier (UUIDv4)
> > > @@ -125,6 +131,67 @@ static int tee_release(struct inode *inode, struct file *filp)
> > >  	return 0;
> > >  }
> > >  
> > > +#ifdef CONFIG_TEE_APPID_SECURITY
> > > +static const char *tee_session_get_application_id(void **data)
> > static char *get_app_id(void) should be enough.
> > 
> > > +{
> > > +	struct file *exe_file;
> > > +	const char *name = CONFIG_TEE_APPID_SECURITY_XATTR;
> > > +	int len;
> > > +
> > > +	exe_file = get_mm_exe_file(current->mm);
> > > +	if (!exe_file)
> > > +		return ERR_PTR(-ENOENT);
> > > +
> > > +	if (!exe_file->f_inode) {
> > > +		fput(exe_file);
> > > +		return ERR_PTR(-ENOENT);
> > > +	}
> > > +
> > 
> > You could perhaps add a comment here on the expected properties of this
> > data. Something along (don't know if I'm even close) "string
> > representation of the the hash of the binary and time stamp".
> > 
> > > +	len = security_inode_getsecurity(exe_file->f_inode, name, data, true);
> > > +	if (len < 0)
> > > +		return ERR_PTR(len);
> > > +
> > > +	fput(exe_file);
> > > +
> > > +	return *data;
> > > +}
> > > +#endif /* CONFIG_TEE_APPID_SECURITY */
> > > +
> > > +#ifdef CONFIG_TEE_APPID_PATH
> > > +static const char *tee_session_get_application_id(void **data)
> > > +{
> > > +	struct file *exe_file;
> > > +	char *path;
> > > +
> > > +	*data = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL);
> > > +	if (!*data)
> > > +		return ERR_PTR(-ENOMEM);
> > > +
> > > +	exe_file = get_mm_exe_file(current->mm);
> > > +	if (!exe_file) {
> > > +		kfree(*data);
> > > +		return ERR_PTR(-ENOENT);
> > > +	}
> > > +
> > > +	path = file_path(exe_file, *data, TEE_UUID_NS_NAME_SIZE);
> > > +	if (IS_ERR(path)) {
> > > +		kfree(*data);
> > > +		return path;
> > > +	}
> > > +
> > > +	fput(exe_file);
> > > +
> > > +	return path;
> > > +}
> > > +#endif /* CONFIG_TEE_APPID_PATH */
> > > +
> > > +#if defined(CONFIG_TEE_APPID_PATH) || defined(CONFIG_TEE_APPID_SECURITY)
> > > +static void tee_session_free_application_id(void *data)
> > > +{
> > > +	kfree(data);
> > > +}
> > This function isn't needed, we can call kfree() directly.
> > 
> > > +#endif /* CONFIG_TEE_APPID_PATH || CONFIG_TEE_APPID_SECURITY */
> > > +
> > >  /**
> > >   * uuid_v5() - Calculate UUIDv5
> > >   * @uuid: Resulting UUID
> > > @@ -197,6 +264,8 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
> > >  	gid_t ns_grp = (gid_t)-1;
> > >  	kgid_t grp = INVALID_GID;
> > >  	char *name = NULL;
> > > +	void *application_id_data = NULL;
> > This isn't needed
> The only reason application_id_data exists (and get_application_id has a parameter)
> is because when defined(CONFIG_TEE_APPID_PATH), file_path() returns a pointer
> that often starts at an offset into the buffer (see the comment above d_path()).
> Therefore we end up with a buffer that's not equal to application_id which we
> want to free later. The other way (other than having a void **data parameter)
> would be to allocate a new buffer, copy the resulting path there, and return
> the new buffer instead of the one used by file_path().
> Let me know which solution is preferred.

Good point. Please use the pattern you're already using. I'd prefer a slightly
shorter name though. app_id_data perhaps?

Thanks,
Jens

> 
> > > +	const char *application_id = NULL;
> > char *app_id = NULL;
> > 
> > >  	int name_len;
> > >  	int rc;
> > >  
> > > @@ -217,6 +286,14 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
> > >  	 * For TEEC_LOGIN_GROUP:
> > >  	 * gid=<gid>
> > >  	 *
> > > +	 * For TEEC_LOGIN_APPLICATION:
> > > +	 * app=<application id>
> > > +	 *
> > > +	 * For TEEC_LOGIN_USER_APPLICATION:
> > > +	 * uid=<uid>:app=<application id>
> > > +	 *
> > > +	 * For TEEC_LOGIN_GROUP_APPLICATION:
> > > +	 * gid=<gid>:app=<application id>
> > >  	 */
> > >  
> > >  	name = kzalloc(TEE_UUID_NS_NAME_SIZE, GFP_KERNEL);
> > > @@ -249,6 +326,63 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
> > >  		}
> > >  		break;
> > >  
> > > +	case TEE_IOCTL_LOGIN_APPLICATION:
> > > +		application_id = tee_session_get_application_id(&application_id_data);
> > > +		if (IS_ERR(application_id)) {
> > > +			rc = PTR_ERR(application_id);
> > > +			goto out_free_name;
> > > +		}
> > > +
> > > +		name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "app=%s",
> > > +				    application_id);
> > > +		tee_session_free_application_id(application_id_data);
> > > +
> > > +		if (name_len >= TEE_UUID_NS_NAME_SIZE) {
> > > +			rc = -E2BIG;
> > > +			goto out_free_name;
> > > +		}
> > It looks like we remove these tests and replace them with
> > if (name_len < TEE_UUID_NS_NAME_SIZE)
> >         rc = uuid_v5(uuid, &tee_client_uuid_ns, name, name_len);
> > else
> >         rc = -E2BIG
> > 
> > below, just above the "out_free_name:" label.
> > 
> > This function is small and simple enough that it should be easy to see
> > what's going on any way.
> > 
> > Thanks,
> > Jens
> > 
> > > +		break;
> > > +
> > > +	case TEE_IOCTL_LOGIN_USER_APPLICATION:
> > > +		application_id = tee_session_get_application_id(&application_id_data);
> > > +		if (IS_ERR(application_id)) {
> > > +			rc = PTR_ERR(application_id);
> > > +			goto out_free_name;
> > > +		}
> > > +
> > > +		name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "uid=%x:app=%s",
> > > +				    current_euid().val, application_id);
> > > +		tee_session_free_application_id(application_id_data);
> > > +
> > > +		if (name_len >= TEE_UUID_NS_NAME_SIZE) {
> > > +			rc = -E2BIG;
> > > +			goto out_free_name;
> > > +		}
> > > +		break;
> > > +
> > > +	case TEE_IOCTL_LOGIN_GROUP_APPLICATION:
> > > +		memcpy(&ns_grp, connection_data, sizeof(gid_t));
> > > +		grp = make_kgid(current_user_ns(), ns_grp);
> > > +		if (!gid_valid(grp) || !in_egroup_p(grp)) {
> > > +			rc = -EPERM;
> > > +			goto out_free_name;
> > > +		}
> > > +
> > > +		application_id = tee_session_get_application_id(&application_id_data);
> > > +		if (IS_ERR(application_id)) {
> > > +			rc = PTR_ERR(application_id);
> > > +			goto out_free_name;
> > > +		}
> > > +		name_len = snprintf(name, TEE_UUID_NS_NAME_SIZE, "gid=%x:app=%s",
> > > +				    grp.val, application_id);
> > > +		tee_session_free_application_id(application_id_data);
> > > +
> > > +		if (name_len >= TEE_UUID_NS_NAME_SIZE) {
> > > +			rc = -E2BIG;
> > > +			goto out_free_name;
> > > +		}
> > > +		break;
> > > +
> > >  	default:
> > >  		rc = -EINVAL;
> > >  		goto out_free_name;
> > > -- 
> > > 2.28.0
> > > 
> 

  reply	other threads:[~2020-09-30  6:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 15:38 [RFC PATCH] tee: add support for application-based session login methods Elvira Khabirova
2020-09-28 13:43 ` Jens Wiklander
2020-09-30  2:01   ` Elvira Khabirova
2020-09-30  6:11     ` Jens Wiklander [this message]
     [not found] <010001749cbe8c36-0330f6a3-10a0-4835-b799-570cb9bfa1e0-000000@email.amazonses.com>
2020-09-28  9:49 ` Elvira Khabirova

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=20200930061153.GA738306@jade \
    --to=jens.wiklander@linaro.org \
    --cc=e.khabirova@omprussia.ru \
    --cc=k.karasev@omprussia.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=s.shtylyov@omprussia.ru \
    --cc=vesa.jaaskelainen@vaisala.com \
    /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).