All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Weigelt <lkml@metux.net>
To: Richard Weinberger <richard.weinberger@gmail.com>,
	"Enrico Weigelt, metux IT consult" <metux@gmx.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] p9caps: add Plan9 capability devices
Date: Wed, 25 Apr 2018 12:38:02 +0200	[thread overview]
Message-ID: <3ffb5399-46b8-7279-fda2-2ca5b40c04d3@metux.net> (raw)
In-Reply-To: <CAFLxGvwHebXuQYwOdG_vnYfjwtdMfCHg5srzjsj1fEaCFm2QGw@mail.gmail.com>

On 17.02.2018 23:11, Richard Weinberger wrote:

Hi,

>> +static LIST_HEAD(caphash_writers); >> +>> +static DEFINE_MUTEX(lock);>> +>> +struct crypto_ahash *hmac_tfm 
= NULL;>> +>> +static int caphash_open(struct inode *inode, struct file 
*filp)>> +{>> +       struct caphash_writer *tmp = NULL;>> + 
struct user_namespace *user_ns = current_user_ns();>> +       int retval 
= 0;>> +       struct list_head *pos, *q;>> +>> +       /* make sure 
only one instance per namespace can be opened */>> + 
mutex_lock(&lock);>> +>> +       list_for_each_safe(pos, q, 
&(caphash_writers)) {>> +               tmp = list_entry(pos, struct 
caphash_writer, list);>> +               if (tmp->user_ns == user_ns) 
{>> +                       pr_err("already locked in this namespace\n");>
> So, evil guy opens the device but does not close it, therefore the
> whole service is blocked in a namespace?

Yes, exactly as specified. There may be only one host factotum running,
which can create caps. It's an important security feature.

> In general, I think we should open that device in
> kernel_init_freeable() and hand over the fd to init/systemd.

That would require an customized init and factotum, and wouldn't be
Plan9 compatible.

>> +static int caphash_release(struct inode *inode, struct file *filp)
>> +{
>> +       int retval = 0;
>> +       struct user_namespace *user_ns = current_user_ns();
> 
> Why not obtaining the user namespace from the open file?
> That way one can close a caphash file hande she never opened.
> Think of open, followed by nsenter, ...

hmm, good point.

>> +       list_for_each_safe(pos, q, &(caphash_writers)) {
>> +               tmp = list_entry(pos, struct caphash_entry, list);
> 
> list_for_each_entry.

what's the exact difference ?

>> +static ssize_t capuse_write(struct file *filp, const char __user *buf,
>> +                                 size_t count, loff_t *f_pos)
>> +{
>> +       ssize_t retval = count;
>> +       char  *rand_str, *src_uname, *dst_uname;
>> +       u8 hashval[SHA1_DIGEST_SIZE] = { 0 };
>> +       char *cmdbuf;
>> +
>> +       if (!(cmdbuf = kzalloc(count, GFP_KERNEL)))
> 
> count is unbound, please apply a limit check.

ok.

>> +       {
>> +               char *walk = cmdbuf;
> 
> cmdbuf is toxic, make sure it is at least nul-terminated.

ok.

>> +       if (hmac_tfm)
> 
> IS_ERR()? Otherwise you free a error value, if crypto_alloc_ahash() fails.

ok


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  reply	other threads:[~2018-04-25 10:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-10 16:58 [PATCH] p9caps: add Plan9 capability devices Enrico Weigelt, metux IT consult
2018-02-10 17:54 ` Randy Dunlap
2018-02-11 21:50   ` Enrico Weigelt, metux IT consult
2018-02-11 21:50     ` [PATCH] " Enrico Weigelt, metux IT consult
2018-02-13  7:16       ` Serge E. Hallyn
2018-02-13 12:40         ` Enrico Weigelt, metux IT consult
2018-02-14 14:56           ` Serge E. Hallyn
     [not found]             ` <20180214145650.GA2102-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2018-02-14 17:58               ` Enrico Weigelt
2018-02-14 17:58             ` Enrico Weigelt
2018-02-17 22:11       ` Richard Weinberger
2018-04-25 10:38         ` Enrico Weigelt [this message]
2018-04-25 12:23           ` Richard Weinberger
2018-02-10 18:03 ` Al Viro

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=3ffb5399-46b8-7279-fda2-2ca5b40c04d3@metux.net \
    --to=lkml@metux.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=metux@gmx.de \
    --cc=richard.weinberger@gmail.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 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.