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


Groups > linux.kernel > #1658509

Re: [PATCH 4/5] Make LSM Writable Hooks a command line option

From Igor Stoppa <igor.stoppa@huawei.com>
Newsgroups linux.kernel
Subject Re: [PATCH 4/5] Make LSM Writable Hooks a command line option
Date 2017-06-06 11:10 +0200
Message-ID <tPiEW-6IR-29@gated-at.bofh.it> (permalink)
References <tP5Rn-6ZT-3@gated-at.bofh.it> <tP5Ro-6ZT-11@gated-at.bofh.it> <tP6kp-7bv-7@gated-at.bofh.it> <tP7gt-7Lh-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 05/06/17 23:50, Tetsuo Handa wrote:
> Casey Schaufler wrote:

[...]

>> I don't care for calling this "security debug". Making
>> the lists writable after init isn't about development,
>> it's about (Tetsuo's desire for) dynamic module loading.
>> I would prefer "dynamic_module_lists" our something else
>> more descriptive.
> 
> Maybe dynamic_lsm ?

ok, apologies for misunderstanding, I'll fix it.

I am not sure I understood what exactly the use case is:
-1) loading off-tree modules
-2) loading and unloading modules
-3) something else ?

I'm asking this because I now wonder if I should provide means for
protecting the heads later on (which still can make sense for case 1).

Or if it's expected that things will stay fluid and this dynamic loading
is matched by unloading, therefore the heads must stay writable (case 2)

[...]

>>> +	if (!sec_pool)
>>> +		goto error_pool;
>>
>> Excessive gotoing - return -ENOMEM instead.
> 
> But does it make sense to continue?
> hook_heads == NULL and we will oops as soon as
> call_void_hook() or call_int_hook() is called for the first time.

Shouldn't the caller check for result? -ENOMEM gives it a chance to do
so. I can replace the goto.

---
igor

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


Thread

(none) Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-05 21:30 +0200
  [PATCH 3/5] Protectable Memory Allocator - Debug interface Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-05 21:30 +0200
    Re: [kernel-hardening] [PATCH 3/5] Protectable Memory Allocator -  Debug interface Jann Horn <jannh@google.com> - 2017-06-05 22:30 +0200
      Re: [kernel-hardening] [PATCH 3/5] Protectable Memory Allocator -  Debug interface Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 11:10 +0200
  [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-05 21:30 +0200
    Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Casey Schaufler <casey@schaufler-ca.com> - 2017-06-05 22:00 +0200
      Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-05 23:00 +0200
        Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 11:10 +0200
          Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-06 13:00 +0200
            Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 13:20 +0200
              Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-06 13:50 +0200
                Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 14:20 +0200
                Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-06 16:40 +0200
                Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 17:00 +0200
                Re: [PATCH 4/5] Make LSM Writable Hooks a command line option Casey Schaufler <casey@schaufler-ca.com> - 2017-06-06 17:20 +0200
  [PATCH 2/5] Protectable Memory Allocator Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-05 21:30 +0200
    Re: [PATCH 2/5] Protectable Memory Allocator Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> - 2017-06-06 06:50 +0200
      Re: [PATCH 2/5] Protectable Memory Allocator Christoph Hellwig <hch@infradead.org> - 2017-06-06 08:30 +0200
        Re: [PATCH 2/5] Protectable Memory Allocator Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 13:40 +0200
          Re: [PATCH 2/5] Protectable Memory Allocator Laura Abbott <labbott@redhat.com> - 2017-06-06 18:30 +0200
      Re: [PATCH 2/5] Protectable Memory Allocator Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 13:50 +0200
        Re: [PATCH 2/5] Protectable Memory Allocator Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-06 14:10 +0200
          Re: [PATCH 2/5] Protectable Memory Allocator Igor Stoppa <igor.stoppa@huawei.com> - 2017-06-06 14:30 +0200

csiph-web