Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head
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
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
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
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
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
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
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
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
On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handawrote: > 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
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
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 HandaCc: 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
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, +