[PATCH v7 1/6] security: Move LSM registration arguments to struct lsm_info

Sargun Dhillon sargun at sargun.me
Tue May 1 19:35:58 UTC 2018


On Tue, May 1, 2018 at 12:19 PM, Kees Cook <keescook at chromium.org> wrote:
> On Wed, Apr 25, 2018 at 1:58 AM, Sargun Dhillon <sargun at sargun.me> wrote:
>> Previously, when LSMs registered, they independently passed their name
>> and hook count. This had two implications:
>>
>> 1) Is required us to clone the name, so we could present it in
>>    security FS. This required memory allocation at start time.
>> 2) Every time we wanted to tie more information back from
>>    the security hooks, to the LSM, we would have to add
>>    duplicated fields in struct security_hook_list.
>>
>> It also introduces a new file -- security/security.h, which is meant
>> to be private headers to be shared only between pieces of security
>> "infrastructure".
>>
>> Signed-off-by: Sargun Dhillon <sargun at sargun.me>
>> ---
>>  include/linux/lsm_hooks.h  | 44 ++++++++++-------------
>>  security/apparmor/lsm.c    |  6 ++--
>>  security/commoncap.c       |  8 +++--
>>  security/inode.c           | 56 +++++++++++++++++++++++++----
>>  security/loadpin/loadpin.c |  4 ++-
>>  security/security.c        | 89 +++++++++++++++++++++++-----------------------
>>  security/security.h        | 10 ++++++
>>  security/selinux/hooks.c   |  6 ++--
>>  security/smack/smack_lsm.c |  3 +-
>>  security/tomoyo/tomoyo.c   |  4 ++-
>>  security/yama/yama_lsm.c   |  4 ++-
>>  11 files changed, 147 insertions(+), 87 deletions(-)
>>  create mode 100644 security/security.h
>>
>> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>> index 9d0b286f3dba..65f346cb6639 100644
>> --- a/include/linux/lsm_hooks.h
>> +++ b/include/linux/lsm_hooks.h
>> @@ -2004,11 +2004,20 @@ struct security_hook_heads {
>>   * Security module hook list structure.
>>   * For use with generic list macros for common operations.
>>   */
>> +struct security_hook_list;
>> +struct lsm_info {
>> +       struct hlist_node               list;
>> +       const char                      *name;
>> +       const unsigned int              count;
>> +       struct security_hook_list       *hooks;
>> +} __randomize_layout;
>> +
>>  struct security_hook_list {
>>         struct hlist_node               list;
>>         struct hlist_head               *head;
>>         union security_list_options     hook;
>> -       char                            *lsm;
>> +       /* This field is not currently in use */
>> +       struct lsm_info                 *info;
>
> const?
>
>>  } __randomize_layout;
>>
>>  /*
>> @@ -2020,33 +2029,18 @@ struct security_hook_list {
>>  #define LSM_HOOK_INIT(HEAD, HOOK) \
>>         { .head = &security_hook_heads.HEAD, .hook = { .HEAD = HOOK } }
>>
>> -extern struct security_hook_heads security_hook_heads;
>> -extern char *lsm_names;
>> +#define LSM_MODULE_INIT(NAME, HOOKS)           \
>> +       {                                       \
>> +               .name   = NAME,                 \
>> +               .hooks  = HOOKS,                \
>> +               .count  = ARRAY_SIZE(HOOKS),    \
>> +       }
>
> Instead of leaving this so every LSM has to do all the declarations, how about:
>
> #define LSM_MODULE(NAME) \
>     static const struct lsm_info NAME ## _info = { \
>         .name = #NAME, \
>         .hooks = NAME ## _hooks, \
>         .count = ARRAY_SIZE(NAME ## _hooks), \
>     }
>
>> +static struct lsm_info apparmor_info =
>> +       LSM_MODULE_INIT("apparmor", apparmor_hooks);
>
> This becomes just:
>
> LSM_MODULE(apparmor);
>
>> +static struct lsm_info capability_info =
>> +       LSM_MODULE_INIT("capability", capability_hooks);
>
> LSM_MODULE(capability);
I thought about this, but I think that the implicit aspect of
statically defining "X_hooks" in the same file is kind of confusing.

>
> etc...
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the Linux-security-module-archive mailing list