Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[James Morris]

On Wed, 31 May 2017, Igor Stoppa wrote:

> On 30/05/17 13:32, James Morris wrote:
> 
> > This seems like pointless churn in security-critical code in anticipation 
> > of features which are still in development and may not be adopted.
> > 
> > Is there a compelling reason to merge this now? (And I don't mean worrying 
> > about non-existent compliers).
> 
> I propose to take this patch as part of those I will be submitting.
> It took me some unplanned time to add support for hardened user copy,
> but now it's done - at least to a point that I can test it without failures.
> 
> So I'm back on track to provide an example of the smalloc api and I can
> also use Tetsuo's work (thanks again, btw).
> This patch would be sandwiched between the smalloc ones and the LSM rework.
> 
> It can get merged when the rest (hopefully) is merged.
> 
> But I have a more prosaic question: since smalloc is affecting the
> memory subsystem, can it still be merged through the security tree?

It needs acks from the maintainers of the affected subsystems.

-- 
James Morris

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[James Morris]

On Wed, 31 May 2017, Igor Stoppa wrote:

> On 30/05/17 13:32, James Morris wrote:
> 
> > This seems like pointless churn in security-critical code in anticipation 
> > of features which are still in development and may not be adopted.
> > 
> > Is there a compelling reason to merge this now? (And I don't mean worrying 
> > about non-existent compliers).
> 
> I propose to take this patch as part of those I will be submitting.
> It took me some unplanned time to add support for hardened user copy,
> but now it's done - at least to a point that I can test it without failures.
> 
> So I'm back on track to provide an example of the smalloc api and I can
> also use Tetsuo's work (thanks again, btw).
> This patch would be sandwiched between the smalloc ones and the LSM rework.
> 
> It can get merged when the rest (hopefully) is merged.
> 
> But I have a more prosaic question: since smalloc is affecting the
> memory subsystem, can it still be merged through the security tree?

It needs acks from the maintainers of the affected subsystems.

-- 
James Morris

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Igor Stoppa]

On 30/05/17 13:32, James Morris wrote:

> This seems like pointless churn in security-critical code in anticipation 
> of features which are still in development and may not be adopted.
> 
> Is there a compelling reason to merge this now? (And I don't mean worrying 
> about non-existent compliers).

I propose to take this patch as part of those I will be submitting.
It took me some unplanned time to add support for hardened user copy,
but now it's done - at least to a point that I can test it without failures.

So I'm back on track to provide an example of the smalloc api and I can
also use Tetsuo's work (thanks again, btw).
This patch would be sandwiched between the smalloc ones and the LSM rework.

It can get merged when the rest (hopefully) is merged.

But I have a more prosaic question: since smalloc is affecting the
memory subsystem, can it still be merged through the security tree?

---
thanks, igor

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Igor Stoppa]

On 30/05/17 13:32, James Morris wrote:

> This seems like pointless churn in security-critical code in anticipation 
> of features which are still in development and may not be adopted.
> 
> Is there a compelling reason to merge this now? (And I don't mean worrying 
> about non-existent compliers).

I propose to take this patch as part of those I will be submitting.
It took me some unplanned time to add support for hardened user copy,
but now it's done - at least to a point that I can test it without failures.

So I'm back on track to provide an example of the smalloc api and I can
also use Tetsuo's work (thanks again, btw).
This patch would be sandwiched between the smalloc ones and the LSM rework.

It can get merged when the rest (hopefully) is merged.

But I have a more prosaic question: since smalloc is affecting the
memory subsystem, can it still be merged through the security tree?

---
thanks, igor

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[James Morris]

On Mon, 29 May 2017, Tetsuo Handa wrote:

> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
> 
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
> 
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
> 

This seems like pointless churn in security-critical code in anticipation 
of features which are still in development and may not be adopted.

Is there a compelling reason to merge this now? (And I don't mean worrying 
about non-existent compliers).



-- 
James Morris

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[James Morris]

On Mon, 29 May 2017, Tetsuo Handa wrote:

> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
> 
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
> 
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
> 

This seems like pointless churn in security-critical code in anticipation 
of features which are still in development and may not be adopted.

Is there a compelling reason to merge this now? (And I don't mean worrying 
about non-existent compliers).



-- 
James Morris

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Casey Schaufler]

On 5/28/2017 1:29 PM, Tetsuo Handa wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

I have no substantial objections.
Acked-by: Casey Schaufler 


> ---
>  include/linux/lsm_hooks.h | 412 
> +++---
>  security/security.c   |  31 ++--
>  2 files changed, 223 insertions(+), 220 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 080f34e..ac22be3 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1663,219 +1663,220 @@
>  #endif /* CONFIG_AUDIT */
>  };
>  
> -struct security_hook_heads {
> - struct list_head binder_set_context_mgr;
> - struct list_head binder_transaction;
> - struct list_head binder_transfer_binder;
> - struct list_head binder_transfer_file;
> - struct list_head ptrace_access_check;
> - struct list_head ptrace_traceme;
> - struct list_head capget;
> - struct list_head capset;
> - struct list_head capable;
> - struct list_head quotactl;
> - struct list_head quota_on;
> - struct list_head syslog;
> - struct list_head settime;
> - struct list_head vm_enough_memory;
> - struct list_head bprm_set_creds;
> - struct list_head bprm_check_security;
> - struct list_head bprm_secureexec;
> - struct list_head bprm_committing_creds;
> - struct list_head bprm_committed_creds;
> - struct list_head sb_alloc_security;
> - struct list_head sb_free_security;
> - struct list_head sb_copy_data;
> - struct list_head sb_remount;
> - struct list_head sb_kern_mount;
> - struct list_head sb_show_options;
> - struct list_head sb_statfs;
> - struct list_head sb_mount;
> - struct list_head sb_umount;
> - struct list_head sb_pivotroot;
> - struct list_head sb_set_mnt_opts;
> - struct list_head sb_clone_mnt_opts;
> - struct list_head sb_parse_opts_str;
> - struct list_head dentry_init_security;
> - struct list_head dentry_create_files_as;
> +enum security_hook_index {
> + LSM_binder_set_context_mgr,
> + LSM_binder_transaction,
> + LSM_binder_transfer_binder,
> + LSM_binder_transfer_file,
> + LSM_ptrace_access_check,
> + LSM_ptrace_traceme,
> + LSM_capget,
> + LSM_capset,
> + LSM_capable,
> + LSM_quotactl,
> + LSM_quota_on,
> + LSM_syslog,
> + LSM_settime,
> + LSM_vm_enough_memory,
> 

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Casey Schaufler]

On 5/28/2017 1:29 PM, Tetsuo Handa wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

I have no substantial objections.
Acked-by: Casey Schaufler 


> ---
>  include/linux/lsm_hooks.h | 412 
> +++---
>  security/security.c   |  31 ++--
>  2 files changed, 223 insertions(+), 220 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 080f34e..ac22be3 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1663,219 +1663,220 @@
>  #endif /* CONFIG_AUDIT */
>  };
>  
> -struct security_hook_heads {
> - struct list_head binder_set_context_mgr;
> - struct list_head binder_transaction;
> - struct list_head binder_transfer_binder;
> - struct list_head binder_transfer_file;
> - struct list_head ptrace_access_check;
> - struct list_head ptrace_traceme;
> - struct list_head capget;
> - struct list_head capset;
> - struct list_head capable;
> - struct list_head quotactl;
> - struct list_head quota_on;
> - struct list_head syslog;
> - struct list_head settime;
> - struct list_head vm_enough_memory;
> - struct list_head bprm_set_creds;
> - struct list_head bprm_check_security;
> - struct list_head bprm_secureexec;
> - struct list_head bprm_committing_creds;
> - struct list_head bprm_committed_creds;
> - struct list_head sb_alloc_security;
> - struct list_head sb_free_security;
> - struct list_head sb_copy_data;
> - struct list_head sb_remount;
> - struct list_head sb_kern_mount;
> - struct list_head sb_show_options;
> - struct list_head sb_statfs;
> - struct list_head sb_mount;
> - struct list_head sb_umount;
> - struct list_head sb_pivotroot;
> - struct list_head sb_set_mnt_opts;
> - struct list_head sb_clone_mnt_opts;
> - struct list_head sb_parse_opts_str;
> - struct list_head dentry_init_security;
> - struct list_head dentry_create_files_as;
> +enum security_hook_index {
> + LSM_binder_set_context_mgr,
> + LSM_binder_transaction,
> + LSM_binder_transfer_binder,
> + LSM_binder_transfer_file,
> + LSM_ptrace_access_check,
> + LSM_ptrace_traceme,
> + LSM_capget,
> + LSM_capset,
> + LSM_capable,
> + LSM_quotactl,
> + LSM_quota_on,
> + LSM_syslog,
> + LSM_settime,
> + LSM_vm_enough_memory,
> + LSM_bprm_set_creds,
> + LSM_bprm_check_security,
> + LSM_bprm_secureexec,
> + LSM_bprm_committing_creds,
> + LSM_bprm_committed_creds,
> + LSM_sb_alloc_security,
> + LSM_sb_free_security,

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Kees Cook]

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
 wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

Looks good to me; thanks for persisting! :)

Acked-by: Kees Cook 

-- 
Kees Cook
Pixel Security

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Kees Cook]

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
 wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we haven't encountered compilers which do not
> treat sizeof(security_hook_heads) != sizeof(struct list_head) *
> (sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
> like the assumption that a structure of N elements can be assumed to be
> the same as an array of N elements.
>
> Now that Kees found that randstruct complains about such casting
>
>   security/security.c: In function 'security_init':
>   security/security.c:59:20: note: found mismatched op0 struct pointer types: 
> 'struct list_head' and 'struct security_hook_heads'
>
> struct list_head *list = (struct list_head *) _hook_heads;
>
> and Christoph thinks that we should fix it rather than make randstruct
> whitelist it, this patch fixes it.
>
> It would be possible to revert commit 3dfc9b02864b19f4, but this patch
> converts security_hook_heads into an explicit array of struct list_head
> by introducing an enum, due to reasons explained below.
>
> Igor proposed a sealable memory allocator, and the LSM hooks
> ("struct security_hook_heads security_hook_heads" and
> "struct security_hook_list ...[]") will benefit from that allocator via
> protection using set_memory_ro()/set_memory_rw(), and that allocator
> will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
> likely be moving to that direction.
>
> This means that these structures will be allocated at run time using
> that allocator, and therefore the address of these structures will be
> determined at run time rather than compile time.
>
> But currently, LSM_HOOK_INIT() macro depends on the address of
> security_hook_heads being known at compile time. If we use an enum
> so that LSM_HOOK_INIT() macro does not need to know absolute address of
> security_hook_heads, it will help us to use that allocator for LSM hooks.
>
> As a result of introducing an enum, security_hook_heads becomes a local
> variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
> rename security_hook_heads to hook_heads.
>
> Signed-off-by: Tetsuo Handa 
> Cc: Kees Cook 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Cc: Igor Stoppa 
> Cc: Christoph Hellwig 

Looks good to me; thanks for persisting! :)

Acked-by: Kees Cook 

-- 
Kees Cook
Pixel Security

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Tetsuo Handa]

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hook_heads) != sizeof(struct list_head) *
(sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
like the assumption that a structure of N elements can be assumed to be
the same as an array of N elements.

Now that Kees found that randstruct complains about such casting

  security/security.c: In function 'security_init':
  security/security.c:59:20: note: found mismatched op0 struct pointer types: 
'struct list_head' and 'struct security_hook_heads'

struct list_head *list = (struct list_head *) _hook_heads;

and Christoph thinks that we should fix it rather than make randstruct
whitelist it, this patch fixes it.

It would be possible to revert commit 3dfc9b02864b19f4, but this patch
converts security_hook_heads into an explicit array of struct list_head
by introducing an enum, due to reasons explained below.

Igor proposed a sealable memory allocator, and the LSM hooks
("struct security_hook_heads security_hook_heads" and
"struct security_hook_list ...[]") will benefit from that allocator via
protection using set_memory_ro()/set_memory_rw(), and that allocator
will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
likely be moving to that direction.

This means that these structures will be allocated at run time using
that allocator, and therefore the address of these structures will be
determined at run time rather than compile time.

But currently, LSM_HOOK_INIT() macro depends on the address of
security_hook_heads being known at compile time. If we use an enum
so that LSM_HOOK_INIT() macro does not need to know absolute address of
security_hook_heads, it will help us to use that allocator for LSM hooks.

As a result of introducing an enum, security_hook_heads becomes a local
variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
rename security_hook_heads to hook_heads.

Signed-off-by: Tetsuo Handa 
Cc: Kees Cook 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Casey Schaufler 
Cc: James Morris 
Cc: Igor Stoppa 
Cc: Christoph Hellwig 
---
 include/linux/lsm_hooks.h | 412 +++---
 security/security.c   |  31 ++--
 2 files changed, 223 insertions(+), 220 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..ac22be3 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1663,219 +1663,220 @@
 #endif /* CONFIG_AUDIT */
 };
 
-struct security_hook_heads {
-   struct list_head binder_set_context_mgr;
-   struct list_head binder_transaction;
-   struct list_head binder_transfer_binder;
-   struct list_head binder_transfer_file;
-   struct list_head ptrace_access_check;
-   struct list_head ptrace_traceme;
-   struct list_head capget;
-   struct list_head capset;
-   struct list_head capable;
-   struct list_head quotactl;
-   struct list_head quota_on;
-   struct list_head syslog;
-   struct list_head settime;
-   struct list_head vm_enough_memory;
-   struct list_head bprm_set_creds;
-   struct list_head bprm_check_security;
-   struct list_head bprm_secureexec;
-   struct list_head bprm_committing_creds;
-   struct list_head bprm_committed_creds;
-   struct list_head sb_alloc_security;
-   struct list_head sb_free_security;
-   struct list_head sb_copy_data;
-   struct list_head sb_remount;
-   struct list_head sb_kern_mount;
-   struct list_head sb_show_options;
-   struct list_head sb_statfs;
-   struct list_head sb_mount;
-   struct list_head sb_umount;
-   struct list_head sb_pivotroot;
-   struct list_head sb_set_mnt_opts;
-   struct list_head sb_clone_mnt_opts;
-   struct list_head sb_parse_opts_str;
-   struct list_head dentry_init_security;
-   struct list_head dentry_create_files_as;
+enum security_hook_index {
+   LSM_binder_set_context_mgr,
+   LSM_binder_transaction,
+   LSM_binder_transfer_binder,
+   LSM_binder_transfer_file,
+   LSM_ptrace_access_check,
+   LSM_ptrace_traceme,
+   LSM_capget,
+   LSM_capset,
+   LSM_capable,
+   LSM_quotactl,
+   LSM_quota_on,
+   LSM_syslog,
+   LSM_settime,
+   LSM_vm_enough_memory,
+   LSM_bprm_set_creds,
+   LSM_bprm_check_security,
+   LSM_bprm_secureexec,
+   LSM_bprm_committing_creds,
+   LSM_bprm_committed_creds,
+   LSM_sb_alloc_security,
+   LSM_sb_free_security,
+   LSM_sb_copy_data,
+   

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

[Tetsuo Handa]

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat sizeof(security_hook_heads) != sizeof(struct list_head) *
(sizeof(security_hook_heads) / sizeof(struct list_head)), Casey does not
like the assumption that a structure of N elements can be assumed to be
the same as an array of N elements.

Now that Kees found that randstruct complains about such casting

  security/security.c: In function 'security_init':
  security/security.c:59:20: note: found mismatched op0 struct pointer types: 
'struct list_head' and 'struct security_hook_heads'

struct list_head *list = (struct list_head *) _hook_heads;

and Christoph thinks that we should fix it rather than make randstruct
whitelist it, this patch fixes it.

It would be possible to revert commit 3dfc9b02864b19f4, but this patch
converts security_hook_heads into an explicit array of struct list_head
by introducing an enum, due to reasons explained below.

Igor proposed a sealable memory allocator, and the LSM hooks
("struct security_hook_heads security_hook_heads" and
"struct security_hook_list ...[]") will benefit from that allocator via
protection using set_memory_ro()/set_memory_rw(), and that allocator
will remove CONFIG_SECURITY_WRITABLE_HOOKS config option. Thus, we will
likely be moving to that direction.

This means that these structures will be allocated at run time using
that allocator, and therefore the address of these structures will be
determined at run time rather than compile time.

But currently, LSM_HOOK_INIT() macro depends on the address of
security_hook_heads being known at compile time. If we use an enum
so that LSM_HOOK_INIT() macro does not need to know absolute address of
security_hook_heads, it will help us to use that allocator for LSM hooks.

As a result of introducing an enum, security_hook_heads becomes a local
variable. In order to pass 80 columns check by scripts/checkpatch.pl ,
rename security_hook_heads to hook_heads.

Signed-off-by: Tetsuo Handa 
Cc: Kees Cook 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Casey Schaufler 
Cc: James Morris 
Cc: Igor Stoppa 
Cc: Christoph Hellwig 
---
 include/linux/lsm_hooks.h | 412 +++---
 security/security.c   |  31 ++--
 2 files changed, 223 insertions(+), 220 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..ac22be3 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1663,219 +1663,220 @@
 #endif /* CONFIG_AUDIT */
 };
 
-struct security_hook_heads {
-   struct list_head binder_set_context_mgr;
-   struct list_head binder_transaction;
-   struct list_head binder_transfer_binder;
-   struct list_head binder_transfer_file;
-   struct list_head ptrace_access_check;
-   struct list_head ptrace_traceme;
-   struct list_head capget;
-   struct list_head capset;
-   struct list_head capable;
-   struct list_head quotactl;
-   struct list_head quota_on;
-   struct list_head syslog;
-   struct list_head settime;
-   struct list_head vm_enough_memory;
-   struct list_head bprm_set_creds;
-   struct list_head bprm_check_security;
-   struct list_head bprm_secureexec;
-   struct list_head bprm_committing_creds;
-   struct list_head bprm_committed_creds;
-   struct list_head sb_alloc_security;
-   struct list_head sb_free_security;
-   struct list_head sb_copy_data;
-   struct list_head sb_remount;
-   struct list_head sb_kern_mount;
-   struct list_head sb_show_options;
-   struct list_head sb_statfs;
-   struct list_head sb_mount;
-   struct list_head sb_umount;
-   struct list_head sb_pivotroot;
-   struct list_head sb_set_mnt_opts;
-   struct list_head sb_clone_mnt_opts;
-   struct list_head sb_parse_opts_str;
-   struct list_head dentry_init_security;
-   struct list_head dentry_create_files_as;
+enum security_hook_index {
+   LSM_binder_set_context_mgr,
+   LSM_binder_transaction,
+   LSM_binder_transfer_binder,
+   LSM_binder_transfer_file,
+   LSM_ptrace_access_check,
+   LSM_ptrace_traceme,
+   LSM_capget,
+   LSM_capset,
+   LSM_capable,
+   LSM_quotactl,
+   LSM_quota_on,
+   LSM_syslog,
+   LSM_settime,
+   LSM_vm_enough_memory,
+   LSM_bprm_set_creds,
+   LSM_bprm_check_security,
+   LSM_bprm_secureexec,
+   LSM_bprm_committing_creds,
+   LSM_bprm_committed_creds,
+   LSM_sb_alloc_security,
+   LSM_sb_free_security,
+   LSM_sb_copy_data,
+   LSM_sb_remount,
+   LSM_sb_kern_mount,
+   LSM_sb_show_options,
+   LSM_sb_statfs,
+   LSM_sb_mount,
+   LSM_sb_umount,
+   LSM_sb_pivotroot,
+   LSM_sb_set_mnt_opts,
+