All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samir Bellabes <sam@synack.fr>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	netfilter-devel@vger.kernel.org, hadi@cyberus.ca,
	kaber@trash.net, zbr@ioremap.net, nhorman@tuxdriver.com,
	root@localdomain.pl, linux-security-module@vger.kernel.org
Subject: Re: [RFC v2 00/10] snet: Security for NETwork syscalls
Date: Mon, 15 Mar 2010 17:43:29 +0100	[thread overview]
Message-ID: <m2wrxdilhq.fsf@ssh.synack.fr> (raw)
In-Reply-To: <201003071445.FJB39029.QLSHtOFOJFOVMF@I-love.SAKURA.ne.jp> (Tetsuo Handa's message of "Sun, 7 Mar 2010 14:45:20 +0900")

Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:

> Hello.
>
> Samir Bellabes wrote:
>> Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
>> 
>> > Regarding [RFC v2 09/10] snet: introduce snet_ticket
>> > +enum snet_verdict snet_ticket_check(struct snet_info *info)
>> > +{
>> > +       struct snet_ticket *st = NULL;
>> > +       unsigned int h = 0, verdict = SNET_VERDICT_NONE;
>> > +       struct list_head *l = NULL;
>> > +       struct snet_task_security *tsec = NULL;
>> > +
>> > +       if (snet_ticket_mode == SNET_TICKET_OFF)
>> > +               goto out;
>> > +
>> > +       tsec = (struct snet_task_security*) current_security();
>> > +
>> > +       h = jhash_2words(info->syscall, info->protocol, 0) % HSIZE;
>> > +       l = &tsec->hash[h];
>> > +
>> > +       read_lock_bh(&tsec->lock);
>> >
>> > Credentials are allocated for copy-on-write basis.
>> > Sharing "tsec" among multiple "struct task_struct" is what you intended?
>> 
>> No, there is no shared "tsec".
>> snet_ticket_check() is called from the process context. So "tsec" is
>> a pointer to the "void *security" pointer from its own "struct
>> task_struct".
>>
> Until 2.6.28:
>
>   "void *security" is directory attached to "struct task_struct".
>   copy_process() calls security_task_alloc().
>
>   Therefore, task1->security != task2->security is guaranteed as long as you do
>
>     task->security = kmalloc();
>
>   at security_task_alloc().
>
> Since 2.6.29:
>
>   "void *security" is attached to "struct cred", and "struct cred *" is
>   attached to "struct task_struct". copy_process() calls copy_creds() and
>   prepare_creds() calls security_prepare_creds(). But copy_creds() does not
>   call prepare_creds() for clone(CLONE_THREAD) case.
>
>   Therefore, task1->cred->security != task2->cred->security is not guaranteed
>   even if you do
>
>     cred->security = kmalloc();
>
>   at security_prepare_creds().
>
>> every task_struct have a "tsec" allocated to its "void *security"
>> pointer. 
>
> You meant to have assigned "void *security" dedicated to "struct task_struct".
> But "void *security" is no longer directly attached to "struct task_struct".
> I couldn't find code that checks whether "current->cred" is used by only
> current thread or not. "current->cred" being used by only current thread is
> a requirement for having a "tsec" allocated to every "struct task_struct".
>
> Your code will share "tsec" among multiple threads if a process created
> threads using clone(CLONE_THREAD | CLONE_SIGHAND | CLONE_VM). Each thread has
> its own "struct task_struct" but they share "cred->security".
> Sharing "tsec" among multiple threads is what you intended?

Hello Tetsuo,

ok, I get your point now.
It seems that this is the common behaviour of credentials, so yes, "tsec"
will be shared between this kind of threads, and it makes sense.

Maybe, I need to protect read-write access to this "tsec" structure.

thank you for this comment Tetsuo,

sam

  reply	other threads:[~2010-03-15 16:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02 20:23 [RFC v2 00/10] snet: Security for NETwork syscalls Samir Bellabes
2010-03-02 20:23 ` [RFC v2 01/10] lsm: add security_socket_closed() Samir Bellabes
2010-03-02 20:23 ` [RFC v2 02/10] Revert "lsm: Remove the socket_post_accept() hook" Samir Bellabes
2010-03-02 20:23 ` [RFC v2 03/10] snet: introduce security/snet, Makefile and Kconfig changes Samir Bellabes
2010-03-03  0:03   ` Greg KH
2010-03-03  0:23     ` Samir Bellabes
2010-03-02 20:23 ` [RFC v2 04/10] snet: introduce snet_core Samir Bellabes
2010-03-02 20:23 ` [RFC v2 05/10] snet: introduce snet_event Samir Bellabes
2010-03-02 20:23 ` [RFC v2 06/10] snet: introduce snet_hooks Samir Bellabes
2010-03-02 20:23 ` [RFC v2 07/10] snet: introduce snet_netlink Samir Bellabes
2010-03-02 20:23 ` [RFC v2 08/10] snet: introduce snet_verdict Samir Bellabes
2010-03-02 20:23 ` [RFC v2 09/10] snet: introduce snet_ticket Samir Bellabes
2010-03-02 20:23 ` [RFC v2 10/10] snet: introduce snet_utils Samir Bellabes
2010-03-03 17:55   ` Jan Engelhardt
2010-03-06 12:41     ` Samir Bellabes
2010-03-03  1:56 ` [RFC v2 00/10] snet: Security for NETwork syscalls Tetsuo Handa
2010-03-06 18:16   ` Samir Bellabes
2010-03-06 18:17   ` Samir Bellabes
2010-03-06 18:20   ` Samir Bellabes
2010-03-06 18:40   ` Samir Bellabes
2010-03-07  5:47     ` Tetsuo Handa
2010-03-06 18:47   ` Samir Bellabes
2010-03-07  5:45     ` Tetsuo Handa
2010-03-15 16:43       ` Samir Bellabes [this message]
2010-03-06 18:50   ` Samir Bellabes

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=m2wrxdilhq.fsf@ssh.synack.fr \
    --to=sam@synack.fr \
    --cc=hadi@cyberus.ca \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=root@localdomain.pl \
    --cc=zbr@ioremap.net \
    /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.