Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1622546

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

Show all headers | View raw

On 4/12/2017 9:22 AM, Djalal Harouni wrote:
> On Tue, Apr 11, 2017 at 6:43 AM, Kees Cook <keescook@chromium.org> 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.
> Well, yes rhashtables can have an overhead especially when reclaiming
> memory back, I could not identify a way how to separate tables unless
> we use cgroups as an ID. Anyway this of course could be added in
> task_struct and updated to work like the capability security hooks
> rather than a proper LSM with its own name. But as noted in the other
> response, we may need task->security field for Yama anyway. I'm open
> to suggestion ? I may try to converge the task->security blob with
> what Casey is proposing and see! otherwise fallback to task_struct as
> a last resort!
>
> Thanks!

I can present a patch set based on my existing stacking
work that includes the move from module based memory
management to infrastructure memory management but pretty
well stops there. There will be changes to Kconfig to allow
stacking of everything except SELinux and Smack, because
that's the only combination with other conficts. Well,
there's /proc/attr, but I'd include the module specific
subdirectories, too. That would allow landlock to come in
and TOMOYO (and potentially YAMA) to use/share the task
blob. I see this as taking down a barrier rather than
otherwise pointless infrastructure change.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

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