Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

From	Casey Schaufler <casey@schaufler-ca.com>
Newsgroups	linux.kernel
Subject	Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.
Date	2017-04-11 22:00 +0200
Message-ID	<tva7g-2VS-9@gated-at.bofh.it> (permalink)
References	(2 earlier) <tuJTs-2D4-21@gated-at.bofh.it> <tuMoh-4s3-23@gated-at.bofh.it> <tuNaF-50X-5@gated-at.bofh.it> <tuNNo-5x7-25@gated-at.bofh.it> <tuVUB-2g1-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 4/10/2017 9:43 PM, Kees Cook wrote:
> On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni <tixxdz@gmail.com> wrote:
>> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> I think that would be the prudent approach. There is still
>>> the possibility that blob sharing (or full stacking, if you
>>> prefer) won't be accepted any time soon.
>> Ok Casey! I will wait for more feedback, and if other maintainers do
>> not object, I will convert it back to rhashtables in next iterations
>> making sure that it should be simple to convert later to a blob
>> sharing mechanism.
> Would it be possible just to add a single field to task_struct if this
> LSM is built in? I feel like rhashtables is a huge overhead when a
> single field is all that's needed.

Special casing the task_struct based on which modules
are compiled in would work, but I'm under the impression
that there's a strong desire to keep to one pointer for
security module information in the major structures.

The code for generalizing shared blobs isn't that hard,
and y'all have seen it many times. It would be perfectly
safe to convert the task, cred, inode and such blobs to
be infrastructure managed right now. That wouldn't mean
that all the stacking issues (e.g. audit and networking)
would be addressed, or that all combinations of modules
would work (i.e. no SELinux+Smack) but it would clear
the way for this case. And Yama could use a blob if it
wanted to.

>
> -Kees
>

Thread

Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct  task_struct" blob. Casey Schaufler <casey@schaufler-ca.com> - 2017-04-10 18:00 +0200
  Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct  task_struct" blob. Djalal Harouni <tixxdz@gmail.com> - 2017-04-10 20:40 +0200
    Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct  task_struct" blob. Casey Schaufler <casey@schaufler-ca.com> - 2017-04-10 21:30 +0200
      Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct  task_struct" blob. Djalal Harouni <tixxdz@gmail.com> - 2017-04-10 22:10 +0200
        Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Kees Cook <keescook@chromium.org> - 2017-04-11 06:50 +0200
          Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Kees Cook <keescook@chromium.org> - 2017-04-11 22:00 +0200
          Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Casey Schaufler <casey@schaufler-ca.com> - 2017-04-11 22:00 +0200
            Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Djalal Harouni <tixxdz@gmail.com> - 2017-04-12 18:10 +0200
          Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Djalal Harouni <tixxdz@gmail.com> - 2017-04-12 18:30 +0200
            Re: [kernel-hardening] Re: [PATCH RFC v2 1/3] LSM: Allow per LSM  module per "struct task_struct" blob. Casey Schaufler <casey@schaufler-ca.com> - 2017-04-12 22:50 +0200

csiph-web