From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: igor.stoppa@huawei.com, casey@schaufler-ca.com,
keescook@chromium.org, mhocko@kernel.org, jmorris@namei.org
Cc: paul@paul-moore.com, sds@tycho.nsa.gov, hch@infradead.org,
labbott@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 4/5] Make LSM Writable Hooks a command line option
Date: Tue, 6 Jun 2017 19:54:05 +0900 [thread overview]
Message-ID: <201706061954.GBH56755.QSOOFMFLtJFVOH@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <ff5714b2-bbb0-726d-2fe6-13d4f1a30a38@huawei.com>
Igor Stoppa wrote:
> 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
Does off-tree mean out-of-tree? If yes, this case is not correct.
"Loading modules which are not compiled as built-in" is correct.
My use case is to allow users to use LSM modules as loadable kernel
modules which distributors do not compile as built-in.
> -2) loading and unloading modules
Unloading LSM modules is dangerous. Only SELinux allows unloading
at the risk of triggering an oops. If we insert delay while removing
list elements, we can easily observe oops due to free function being
called without corresponding allocation function.
> -3) something else ?
Nothing else, as far as I know.
>
> 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.
security_init() is called from start_kernel() in init/main.c , and
errors are silently ignored. Thus, I don't think returning error to
the caller makes sense.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-06-06 10:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 19:22 Igor Stoppa
2017-06-05 19:22 ` [PATCH 1/5] LSM: Convert security_hook_heads into explicit array of struct list_head Igor Stoppa
2017-06-05 19:22 ` [PATCH 2/5] Protectable Memory Allocator Igor Stoppa
2017-06-06 4:44 ` Tetsuo Handa
2017-06-06 6:25 ` Christoph Hellwig
2017-06-06 11:34 ` Igor Stoppa
2017-06-06 16:24 ` Laura Abbott
2017-06-06 11:42 ` Igor Stoppa
2017-06-06 12:08 ` Tetsuo Handa
2017-06-06 12:23 ` Igor Stoppa
2017-06-05 19:22 ` [PATCH 3/5] Protectable Memory Allocator - Debug interface Igor Stoppa
2017-06-05 20:24 ` [kernel-hardening] " Jann Horn
2017-06-06 9:00 ` Igor Stoppa
2017-06-05 19:22 ` [PATCH 4/5] Make LSM Writable Hooks a command line option Igor Stoppa
2017-06-05 19:53 ` Casey Schaufler
2017-06-05 20:50 ` Tetsuo Handa
2017-06-06 8:58 ` Igor Stoppa
2017-06-06 10:54 ` Tetsuo Handa [this message]
2017-06-06 11:12 ` Igor Stoppa
2017-06-06 11:42 ` Tetsuo Handa
2017-06-06 12:11 ` Igor Stoppa
2017-06-06 14:36 ` Tetsuo Handa
2017-06-06 14:51 ` Igor Stoppa
2017-06-06 15:17 ` Casey Schaufler
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=201706061954.GBH56755.QSOOFMFLtJFVOH@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=casey@schaufler-ca.com \
--cc=hch@infradead.org \
--cc=igor.stoppa@huawei.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=paul@paul-moore.com \
--cc=sds@tycho.nsa.gov \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox