This patch shows how it is possible to take advantage of pmalloc:
instead of using the build-time option __lsm_ro_after_init, to decide if
it is possible to keep the hooks modifiable, now this becomes a
boot-time decision, based on the kernel command line.
This patch relies on:
"Convert security_
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 someth
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 pre
On 06/06/17 13:54, Tetsuo Handa wrote:
[...]
> "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.
Ok, so I suppose someone should eventually lock down the
Igor Stoppa wrote:
> Who decides when enough is enough, meaning that all the needed modules
> are loaded?
> Should I provide an interface to user-space? A sysfs entry?
No such interface is needed. Just an API for applying set_memory_rw()
and set_memory_ro() on LSM hooks is enough.
security_add_ho
On 06/06/17 14:42, Tetsuo Handa wrote:
> Igor Stoppa wrote:
>> Who decides when enough is enough, meaning that all the needed modules
>> are loaded?
>> Should I provide an interface to user-space? A sysfs entry?
>
> No such interface is needed. Just an API for applying set_memory_rw()
> and set_
Igor Stoppa wrote:
> For the case at hand, would it work if there was a non-API call that you
> could use until the API is properly expanded?
Kernel command line switching (i.e. this patch) is fine for my use cases.
SELinux folks might want
-static int security_debug;
+static int security_debug
On 06/06/17 17:36, Tetsuo Handa wrote:
> Igor Stoppa wrote:
>> For the case at hand, would it work if there was a non-API call that you
>> could use until the API is properly expanded?
>
> Kernel command line switching (i.e. this patch) is fine for my use cases.
>
> SELinux folks might want
>
>
On 6/6/2017 7:51 AM, Igor Stoppa wrote:
> On 06/06/17 17:36, Tetsuo Handa wrote:
>> Igor Stoppa wrote:
>>> For the case at hand, would it work if there was a non-API call that you
>>> could use until the API is properly expanded?
>> Kernel command line switching (i.e. this patch) is fine for my use
On 6/5/2017 12:22 PM, Igor Stoppa wrote:
> This patch shows how it is possible to take advantage of pmalloc:
> instead of using the build-time option __lsm_ro_after_init, to decide if
> it is possible to keep the hooks modifiable, now this becomes a
> boot-time decision, based on the kernel command
Casey Schaufler wrote:
> > @@ -33,8 +34,17 @@
> > /* Maximum number of letters for an LSM name string */
> > #define SECURITY_NAME_MAX 10
> >
> > -static struct list_head hook_heads[LSM_MAX_HOOK_INDEX]
> > - __lsm_ro_after_init;
> > +static int security_debug;
> > +
> > +static __init int se
11 matches
Mail list logo
