[{"id":1761658,"web_url":"http://patchwork.ozlabs.org/comment/1761658/","msgid":"<1504270223.8240.2.camel@tycho.nsa.gov>","list_archive_url":null,"date":"2017-09-01T12:50:23","subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","submitter":{"id":410,"url":"http://patchwork.ozlabs.org/api/people/410/","name":"Stephen Smalley","email":"sds@tycho.nsa.gov"},"content":"On Thu, 2017-08-31 at 13:56 -0700, Chenbo Feng wrote:\n> From: Chenbo Feng \n> \n> Introduce 5 LSM hooks to provide finer granularity controls on eBPF\n> related operations including create eBPF maps, modify and read eBPF\n> maps\n> content and load eBPF programs to the kernel. Hooks use the new\n> security\n> pointer inside the eBPF map struct to store the owner's security\n> information and the different security modules can perform different\n> checks based on the information stored inside the security field.\n> \n> Signed-off-by: Chenbo Feng \n> ---\n>  include/linux/lsm_hooks.h | 41\n> +++++++++++++++++++++++++++++++++++++++++\n>  include/linux/security.h  | 36 ++++++++++++++++++++++++++++++++++++\n>  security/security.c       | 28 ++++++++++++++++++++++++++++\n>  3 files changed, 105 insertions(+)\n> \n> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h\n> index ce02f76a6188..3aaf9a08a983 100644\n> --- a/include/linux/lsm_hooks.h\n> +++ b/include/linux/lsm_hooks.h\n> @@ -1353,6 +1353,32 @@\n>   *\t@inode we wish to get the security context of.\n>   *\t@ctx is a pointer in which to place the allocated security\n> context.\n>   *\t@ctxlen points to the place to put the length of @ctx.\n> + *\n> + * Security hooks for using the eBPF maps and programs\n> functionalities through\n> + * eBPF syscalls.\n> + *\n> + * @bpf_map_create:\n> + *\tCheck permissions prior to creating a new bpf map.\n> + *\tReturn 0 if the permission is granted.\n> + *\n> + * @bpf_map_modify:\n> + *\tCheck permission prior to insert, update and delete map\n> content.\n> + *\t@map pointer to the struct bpf_map that contains map\n> information.\n> + *\tReturn 0 if the permission is granted.\n> + *\n> + * @bpf_map_read:\n> + *\tCheck permission prior to read a bpf map content.\n> + *\t@map pointer to the struct bpf_map that contains map\n> information.\n> + *\tReturn 0 if the permission is granted.\n> + *\n> + * @bpf_prog_load:\n> + *\tCheck permission prior to load eBPF program.\n> + *\tReturn 0 if the permission is granted.\n> + *\n> + * @bpf_post_create:\n> + *\tInitialize the bpf object security field inside struct\n> bpf_maps and\n> + *\tit is used for future security checks.\n> + *\n>   */\n>  union security_list_options {\n>  \tint (*binder_set_context_mgr)(struct task_struct *mgr);\n> @@ -1685,6 +1711,14 @@ union security_list_options {\n>  \t\t\t\tstruct audit_context *actx);\n>  \tvoid (*audit_rule_free)(void *lsmrule);\n>  #endif /* CONFIG_AUDIT */\n> +\n> +#ifdef CONFIG_BPF_SYSCALL\n> +\tint (*bpf_map_create)(void);\n> +\tint (*bpf_map_read)(struct bpf_map *map);\n> +\tint (*bpf_map_modify)(struct bpf_map *map);\n> +\tint (*bpf_prog_load)(void);\n> +\tint (*bpf_post_create)(struct bpf_map *map);\n> +#endif /* CONFIG_BPF_SYSCALL */\n>  };\n>  \n>  struct security_hook_heads {\n> @@ -1905,6 +1939,13 @@ struct security_hook_heads {\n>  \tstruct list_head audit_rule_match;\n>  \tstruct list_head audit_rule_free;\n>  #endif /* CONFIG_AUDIT */\n> +#ifdef CONFIG_BPF_SYSCALL\n> +\tstruct list_head bpf_map_create;\n> +\tstruct list_head bpf_map_read;\n> +\tstruct list_head bpf_map_modify;\n> +\tstruct list_head bpf_prog_load;\n> +\tstruct list_head bpf_post_create;\n> +#endif /* CONFIG_BPF_SYSCALL */\n>  } __randomize_layout;\n>  \n>  /*\n> diff --git a/include/linux/security.h b/include/linux/security.h\n> index 458e24bea2d4..0656a4f74d14 100644\n> --- a/include/linux/security.h\n> +++ b/include/linux/security.h\n> @@ -31,6 +31,7 @@\n>  #include \n>  #include \n>  #include \n> +#include \n>  \n>  struct linux_binprm;\n>  struct cred;\n> @@ -1735,6 +1736,41 @@ static inline void securityfs_remove(struct\n> dentry *dentry)\n>  \n>  #endif\n>  \n> +#ifdef CONFIG_BPF_SYSCALL\n> +#ifdef CONFIG_SECURITY\n> +int security_map_create(void);\n> +int security_map_modify(struct bpf_map *map);\n> +int security_map_read(struct bpf_map *map);\n> +int security_prog_load(void);\n> +int security_post_create(struct bpf_map *map);\n> +#else\n> +static inline int security_map_create(void)\n> +{\n> +\treturn 0;\n> +}\n> +\n> +static inline int security_map_read(struct bpf_map *map)\n> +{\n> +\treturn 0;\n> +}\n> +\n> +static inline int security_map_modify(struct bpf_map *map)\n> +{\n> +\treturn 0;\n> +}\n> +\n> +static inline int security_prog_load(void)\n> +{\n> +\treturn 0;\n> +}\n> +\n> +static inline int security_post_create(struct bpf_map *map)\n> +{\n> +\treturn 0;\n> +}\n> +#endif /* CONFIG_SECURITY */\n> +#endif /* CONFIG_BPF_SYSCALL */\n\nThese should be named consistently with the ones in lsm_hooks.h and\nshould unambiguously indicate that these are hooks for bpf\nobjects/operations, i.e. security_bpf_map_create(),\nsecurity_bpf_map_read(), etc.\n\nDo you need this level of granularity?\n\nCould you coalesce the map_create() and post_map_create() hooks into\none hook and just unwind the create in that case?\n\nWhy do you label bpf maps but not bpf progs? Should we be controlling\nthe ability to attach/detach a bpf prog (partly controlled by\nCAP_NET_ADMIN, but also somewhat broad in scope and doesn't allow\ncontrol based on who created the prog)?\n\nShould there be a top-level security_bpf_use() hook and permission\ncheck that limits ability to use bpf() at all?\n\n> +\n>  #ifdef CONFIG_SECURITY\n>  \n>  static inline char *alloc_secdata(void)\n> diff --git a/security/security.c b/security/security.c\n> index 55b5997e4b72..02272f93a89e 100644\n> --- a/security/security.c\n> +++ b/security/security.c\n> @@ -12,6 +12,7 @@\n>   *\t(at your option) any later version.\n>   */\n>  \n> +#include \n>  #include \n>  #include \n>  #include \n> @@ -1708,3 +1709,30 @@ int security_audit_rule_match(u32 secid, u32\n> field, u32 op, void *lsmrule,\n>  \t\t\t\tactx);\n>  }\n>  #endif /* CONFIG_AUDIT */\n> +\n> +#ifdef CONFIG_BPF_SYSCALL\n> +int security_map_create(void)\n> +{\n> +\treturn call_int_hook(bpf_map_create, 0);\n> +}\n> +\n> +int security_map_modify(struct bpf_map *map)\n> +{\n> +\treturn call_int_hook(bpf_map_modify, 0, map);\n> +}\n> +\n> +int security_map_read(struct bpf_map *map)\n> +{\n> +\treturn call_int_hook(bpf_map_read, 0, map);\n> +}\n> +\n> +int security_prog_load(void)\n> +{\n> +\treturn call_int_hook(bpf_prog_load, 0);\n> +}\n> +\n> +int security_post_create(struct bpf_map *map)\n> +{\n> +\treturn call_int_hook(bpf_post_create, 0, map);\n> +}\n> +#endif /* CONFIG_BPF_SYSCALL */","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkK396mDbz9s7c\n\tfor ;\n\tFri, 1 Sep 2017 22:55:17 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751918AbdIAMzN (ORCPT );\n\tFri, 1 Sep 2017 08:55:13 -0400","from uhil19pa12.eemsg.mail.mil ([214.24.21.85]:18398 \"EHLO\n\tuhil19pa12.eemsg.mail.mil\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S1751715AbdIAMzM (ORCPT\n\t); Fri, 1 Sep 2017 08:55:12 -0400","from emsm-gh1-uea11.ncsc.mil ([214.29.60.3])\n\tby uhil19pa12.eemsg.mail.mil with ESMTP/TLS/AES256-SHA;\n\t01 Sep 2017 12:45:42 +0000","from unknown (HELO tarius.tycho.ncsc.mil) ([144.51.242.1])\n\tby emsm-gh1-uea11.NCSC.MIL with ESMTP; 01 Sep 2017 12:45:41 +0000","from moss-pluto.infosec.tycho.ncsc.mil (moss-pluto\n\t[192.168.25.131])\n\tby tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v81Cjeo2007920;\n\tFri, 1 Sep 2017 08:45:40 -0400"],"X-Greylist":"delayed 569 seconds by postgrey-1.27 at vger.kernel.org;\n\tFri, 01 Sep 2017 08:55:12 EDT","X-IronPort-AV":"E=Sophos;i=\"5.41,458,1498521600\"; d=\"scan'208\";a=\"1840698\"","IronPort-PHdr":"9a23:IIn42hGEXeLqC4hg53bF6J1GYnF86YWxBRYc798ds5kLTJ76psu5bnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7Sc8kaRW5cVchPUSJPDJ63Y48WA+YfIepUqo/wrEYMoxSjHwmhHODhxCJIiHHo06M10eohEQba0wInEN0Av2/ZrMn2OaoITey41rXEwDfFYvhL2Tn98o/IchU5rP+RQbJ/b9LRyUkxGAPDk16etInlMCmR1uQJrWea7/drWOW0i2E6sAF8uSSvx8cwhYnJgYIZ0FbE9T5jz4ovKt24T1B7bMeiHZBNtC+aL5N7Tt4tTmxnoio3yqAKtYSlcCUF1pgr3QPTZvqaeIaS+B3jTvyeITJgiXJgf7Kwmgi9/FC7yu35Ssm0yFFKrjdZktXUtnACyRjT6s+fR/th5EihwzeP1x3I6u1ePUA1lbbUK54mwrIqkJocrV/DETPslEXzja+Wcl0o+umu6+v5frXrvoKQOoB7hw3kMqkih9azDfo3PwQQRWSX5Pyw1Lj58k34RLVKgOc2kq7csJ3CPsQUu7W5DhRJ0ocj9xm/DzCm3M4enXkcNl1JYh2Hj4/3O13WOvD3Ee+/g0iwkDds3/3GOrrhAo/TIXjFkbbheq1w60FbyAo0wtBf44xbBqsdL/L0X0/7rMbYAQMhMwyo3+bnD81w2ZkaWW2RDa6WLqLSvUWT5uIzOeaMfogVuCj6K/gk+/7uimE5lEQSfamsx5QXaXS4Eu56LEWeZHrmms0BHnsSvgoiUOzqj0WPUThNaHauQq0z+C87BZm4DYfMWI+tmqaN3CSlEZ1MYGBJFFSMHW3vd4WeVPcGcDiSLdN5kjwYSbihTJcs1R+wuw/8xLpoMvHZ+iIftZLk29h14/PcmQsu+jxzCsSXy3uNQH1snmMUWz8227hyoUh8yleFzKh5jOVUFcdN6PxVTwc6L5/cz/B6CtzrXwLBecqGSEuiQtq4GjwxUN0xzMEUY0pnGNWtkArD3yy0DL8RjbCLA4Y08q3E1XjrO8l902rG1LUmj1Q+XsRPNXOphqhk+AjUCY7GjUOZl6mweaQfwiHN7mGDwnSKvExDXw5wVL/KXXEbZkfMsdv54UbCHPeSDuEMMgZHw8nKBKZMZZW9hlVLQv3kNtnYbCSyln22CBKgybaFbY6scGIYimGVDEkCjhBW5nuNKBI/GjbkpmXSEThjPUzgblmq8uRkrn6/CEguwFKkdUpkgoGp9wYViPrUcPYa2rYJqW91sDlvNEqs1NLRTdybrkxue7sKMoB120tOyW+M7181BZenNa03wwdEKwk=","X-IPAS-Result":"A2AjAgAcValZ/wHyM5BcGQEBAQEBAQEBAQEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgwQrgXmDd5o+PgEBAQaBKpdbA1yFRwKEFFcBAQEBAQEBAQIBaiiCMyQBgkABAQEBAyMPAUYQCQINCAMCAiYCAlcGARKID4IVDZEonWaCJyICizwBAQEBAQEBAwEBAQEBASKBDYIdggKBB4VShSGCZ4JhAQSgcpRRghOJVw2Gd4l5jE5XTj8oCgIfCCIPg26BcxyCAyQ2iwIBAQE","Message-ID":"<1504270223.8240.2.camel@tycho.nsa.gov>","Subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","From":"Stephen Smalley ","To":"Chenbo Feng ,\n\tlinux-security-module@vger.kernel.org","Cc":"Chenbo Feng , SELinux ,\n\tnetdev@vger.kernel.org,\n\tAlexei Starovoitov , lorenzo@google.com","Date":"Fri, 01 Sep 2017 08:50:23 -0400","In-Reply-To":"<20170831205635.80256-2-chenbofeng.kernel@gmail.com>","References":"<20170831205635.80256-1-chenbofeng.kernel@gmail.com>\n\t<20170831205635.80256-2-chenbofeng.kernel@gmail.com>","Organization":"National Security Agency","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.6 (3.22.6-2.fc25) ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1763701,"web_url":"http://patchwork.ozlabs.org/comment/1763701/","msgid":"","list_archive_url":null,"date":"2017-09-05T22:24:22","subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","submitter":{"id":72270,"url":"http://patchwork.ozlabs.org/api/people/72270/","name":"Chenbo Feng","email":"fengc@google.com"},"content":"On Fri, Sep 1, 2017 at 5:50 AM, Stephen Smalley wrote:\n> On Thu, 2017-08-31 at 13:56 -0700, Chenbo Feng wrote:\n>> From: Chenbo Feng \n>>\n>> Introduce 5 LSM hooks to provide finer granularity controls on eBPF\n>> related operations including create eBPF maps, modify and read eBPF\n>> maps\n>> content and load eBPF programs to the kernel. Hooks use the new\n>> security\n>> pointer inside the eBPF map struct to store the owner's security\n>> information and the different security modules can perform different\n>> checks based on the information stored inside the security field.\n>>\n>> Signed-off-by: Chenbo Feng \n>> ---\n>> include/linux/lsm_hooks.h | 41\n>> +++++++++++++++++++++++++++++++++++++++++\n>> include/linux/security.h | 36 ++++++++++++++++++++++++++++++++++++\n>> security/security.c | 28 ++++++++++++++++++++++++++++\n>> 3 files changed, 105 insertions(+)\n>>\n>> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h\n>> index ce02f76a6188..3aaf9a08a983 100644\n>> --- a/include/linux/lsm_hooks.h\n>> +++ b/include/linux/lsm_hooks.h\n>> @@ -1353,6 +1353,32 @@\n>> * @inode we wish to get the security context of.\n>> * @ctx is a pointer in which to place the allocated security\n>> context.\n>> * @ctxlen points to the place to put the length of @ctx.\n>> + *\n>> + * Security hooks for using the eBPF maps and programs\n>> functionalities through\n>> + * eBPF syscalls.\n>> + *\n>> + * @bpf_map_create:\n>> + * Check permissions prior to creating a new bpf map.\n>> + * Return 0 if the permission is granted.\n>> + *\n>> + * @bpf_map_modify:\n>> + * Check permission prior to insert, update and delete map\n>> content.\n>> + * @map pointer to the struct bpf_map that contains map\n>> information.\n>> + * Return 0 if the permission is granted.\n>> + *\n>> + * @bpf_map_read:\n>> + * Check permission prior to read a bpf map content.\n>> + * @map pointer to the struct bpf_map that contains map\n>> information.\n>> + * Return 0 if the permission is granted.\n>> + *\n>> + * @bpf_prog_load:\n>> + * Check permission prior to load eBPF program.\n>> + * Return 0 if the permission is granted.\n>> + *\n>> + * @bpf_post_create:\n>> + * Initialize the bpf object security field inside struct\n>> bpf_maps and\n>> + * it is used for future security checks.\n>> + *\n>> */\n>> union security_list_options {\n>> int (*binder_set_context_mgr)(struct task_struct *mgr);\n>> @@ -1685,6 +1711,14 @@ union security_list_options {\n>> struct audit_context *actx);\n>> void (*audit_rule_free)(void *lsmrule);\n>> #endif /* CONFIG_AUDIT */\n>> +\n>> +#ifdef CONFIG_BPF_SYSCALL\n>> + int (*bpf_map_create)(void);\n>> + int (*bpf_map_read)(struct bpf_map *map);\n>> + int (*bpf_map_modify)(struct bpf_map *map);\n>> + int (*bpf_prog_load)(void);\n>> + int (*bpf_post_create)(struct bpf_map *map);\n>> +#endif /* CONFIG_BPF_SYSCALL */\n>> };\n>>\n>> struct security_hook_heads {\n>> @@ -1905,6 +1939,13 @@ struct security_hook_heads {\n>> struct list_head audit_rule_match;\n>> struct list_head audit_rule_free;\n>> #endif /* CONFIG_AUDIT */\n>> +#ifdef CONFIG_BPF_SYSCALL\n>> + struct list_head bpf_map_create;\n>> + struct list_head bpf_map_read;\n>> + struct list_head bpf_map_modify;\n>> + struct list_head bpf_prog_load;\n>> + struct list_head bpf_post_create;\n>> +#endif /* CONFIG_BPF_SYSCALL */\n>> } __randomize_layout;\n>>\n>> /*\n>> diff --git a/include/linux/security.h b/include/linux/security.h\n>> index 458e24bea2d4..0656a4f74d14 100644\n>> --- a/include/linux/security.h\n>> +++ b/include/linux/security.h\n>> @@ -31,6 +31,7 @@\n>> #include \n>> #include \n>> #include \n>> +#include \n>>\n>> struct linux_binprm;\n>> struct cred;\n>> @@ -1735,6 +1736,41 @@ static inline void securityfs_remove(struct\n>> dentry *dentry)\n>>\n>> #endif\n>>\n>> +#ifdef CONFIG_BPF_SYSCALL\n>> +#ifdef CONFIG_SECURITY\n>> +int security_map_create(void);\n>> +int security_map_modify(struct bpf_map *map);\n>> +int security_map_read(struct bpf_map *map);\n>> +int security_prog_load(void);\n>> +int security_post_create(struct bpf_map *map);\n>> +#else\n>> +static inline int security_map_create(void)\n>> +{\n>> + return 0;\n>> +}\n>> +\n>> +static inline int security_map_read(struct bpf_map *map)\n>> +{\n>> + return 0;\n>> +}\n>> +\n>> +static inline int security_map_modify(struct bpf_map *map)\n>> +{\n>> + return 0;\n>> +}\n>> +\n>> +static inline int security_prog_load(void)\n>> +{\n>> + return 0;\n>> +}\n>> +\n>> +static inline int security_post_create(struct bpf_map *map)\n>> +{\n>> + return 0;\n>> +}\n>> +#endif /* CONFIG_SECURITY */\n>> +#endif /* CONFIG_BPF_SYSCALL */\n>\n> These should be named consistently with the ones in lsm_hooks.h and\n> should unambiguously indicate that these are hooks for bpf\n> objects/operations, i.e. security_bpf_map_create(),\n> security_bpf_map_read(), etc.\n>\nThanks for pointing out, will fix this.\n> Do you need this level of granularity?\n>\nThe cover letter of this patch series described a possible use cases of\nthese lsm hooks and this level of granularity would be ideal to reach that\ngoal. We can also implement two hooks such as bpf_obj_create and\nbpf_obj_use to restrict the creation and using when get the bpf fd from\nkernel. But that will be less powerful and flexible.\n> Could you coalesce the map_create() and post_map_create() hooks into\n> one hook and just unwind the create in that case?\n>\nOkay, I will take a look on how to fix this.\n> Why do you label bpf maps but not bpf progs? Should we be controlling\n> the ability to attach/detach a bpf prog (partly controlled by\n> CAP_NET_ADMIN, but also somewhat broad in scope and doesn't allow\n> control based on who created the prog)?\n>\n> Should there be a top-level security_bpf_use() hook and permission\n> check that limits ability to use bpf() at all?\n>\nThis could be useful but having additional lsm hooks check when reading\nand write to eBPF maps may cause performance issue. Instead maybe we\ncould have a hook for creating eBPF object and retrieve object fd to restrict\nthe access.\n>> +\n>> #ifdef CONFIG_SECURITY\n>>\n>> static inline char *alloc_secdata(void)\n>> diff --git a/security/security.c b/security/security.c\n>> index 55b5997e4b72..02272f93a89e 100644\n>> --- a/security/security.c\n>> +++ b/security/security.c\n>> @@ -12,6 +12,7 @@\n>> * (at your option) any later version.\n>> */\n>>\n>> +#include \n>> #include \n>> #include \n>> #include \n>> @@ -1708,3 +1709,30 @@ int security_audit_rule_match(u32 secid, u32\n>> field, u32 op, void *lsmrule,\n>> actx);\n>> }\n>> #endif /* CONFIG_AUDIT */\n>> +\n>> +#ifdef CONFIG_BPF_SYSCALL\n>> +int security_map_create(void)\n>> +{\n>> + return call_int_hook(bpf_map_create, 0);\n>> +}\n>> +\n>> +int security_map_modify(struct bpf_map *map)\n>> +{\n>> + return call_int_hook(bpf_map_modify, 0, map);\n>> +}\n>> +\n>> +int security_map_read(struct bpf_map *map)\n>> +{\n>> + return call_int_hook(bpf_map_read, 0, map);\n>> +}\n>> +\n>> +int security_prog_load(void)\n>> +{\n>> + return call_int_hook(bpf_prog_load, 0);\n>> +}\n>> +\n>> +int security_post_create(struct bpf_map *map)\n>> +{\n>> + return call_int_hook(bpf_post_create, 0, map);\n>> +}\n>> +#endif /* CONFIG_BPF_SYSCALL */","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"CYEMlGcc\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xn1V83WcWz9s83\n\tfor ;\n\tWed, 6 Sep 2017 08:24:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753762AbdIEWY1 (ORCPT );\n\tTue, 5 Sep 2017 18:24:27 -0400","from mail-lf0-f41.google.com ([209.85.215.41]:34218 \"EHLO\n\tmail-lf0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753048AbdIEWYY (ORCPT\n\t); Tue, 5 Sep 2017 18:24:24 -0400","by mail-lf0-f41.google.com with SMTP id l196so13922298lfl.1\n\tfor ; Tue, 05 Sep 2017 15:24:23 -0700 (PDT)","by 10.46.76.1 with HTTP; Tue, 5 Sep 2017 15:24:22 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=google.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=5gT0VRhMy3La/haqsK4o2KWx1EH5BaIvFBC9HtYAmUw=;\n\tb=CYEMlGcciH9TJP/Au5A7kXdzBUi1Mjy6B1VpHmmLoNcO9DrjEYGMqC+N9rHzKFiaVL\n\tdJXW7BtmB8PzSqFHbL7SbKv0rQmrBmJeoRNG5pbePBBCILzcDf96U/W/Sa+Owi5Wb/7o\n\tPjoVccmXzRY0MypSzMifWqoU5UxnqEnFNe39luq1S3F0MHFLqAgFbEDNBa29+5u94kM0\n\txTHMf81n4OMUfQ2VDZuMJeZvxLJOF7f8Ts6cylNwKrVlauBHTE6KasFKlVCG+vu33XzU\n\tqrfvM3yZIERHA8s4X35i9Wd2yswRv49kVbmAdmj66NLsm89j8YcxhU3RSpz6ntRBU+FQ\n\temKA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=5gT0VRhMy3La/haqsK4o2KWx1EH5BaIvFBC9HtYAmUw=;\n\tb=jSLTwF4Mok2uApH8DCYBL2nvbJuRP/OAna3230ku6PQZoUe19DI0zbxh5xXCHlpbav\n\tdMRm0atQw+zf2PnvZIr1XgbKWA3vQQvP4q/pTdq6TZSz7vZizgfDLmMsJD02Gpja1OmM\n\tz1WNfQnVzRMPZwiyhnVw7Fnjs32YwxBu9Fxx2p+LPWWVNfJ2DmNJQh22XniBdi3EUEhj\n\t0tyyx2oViZbbSTDj5EavUkcclMSbLWIsE52NUNc3dbEELKLAkz5KkNmdc/QTwj3kW0+s\n\tnBBeNEn17uLyO9VIpinLAO0Usgb4A5mbSM/16D4lIVS0eiILjKFCf+az3Sj3WT3hOO47\n\tknng==","X-Gm-Message-State":"AHPjjUjxtFknnfK9NkbmpKI2KVy3jR76RUTz+5cetHaDY3zgQxgl6poj\n\tdrIKgCOosGhH+sMtjFSEfXJq9gyi8HZp","X-Google-Smtp-Source":"ADKCNb4juBEVP9W2vOvlZ/XclNfbkGIpaICHwrCRYXbm0ZIR+l8q1a4LMUzLM2qbytU5YSrwMUYStd96EdsVf411lQM=","X-Received":"by 10.25.207.6 with SMTP id f6mr193618lfg.14.1504650262576; Tue,\n\t05 Sep 2017 15:24:22 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<1504270223.8240.2.camel@tycho.nsa.gov>","References":"<20170831205635.80256-1-chenbofeng.kernel@gmail.com>\n\t<20170831205635.80256-2-chenbofeng.kernel@gmail.com>\n\t<1504270223.8240.2.camel@tycho.nsa.gov>","From":"Chenbo Feng ","Date":"Tue, 5 Sep 2017 15:24:22 -0700","Message-ID":"","Subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","To":"Stephen Smalley ","Cc":"Chenbo Feng ,\n\tlinux-security-module@vger.kernel.org,\n\tSELinux , netdev@vger.kernel.org,\n\tAlexei Starovoitov ,\n\tLorenzo Colitti ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1764694,"web_url":"http://patchwork.ozlabs.org/comment/1764694/","msgid":"<1504787539.22845.1.camel@tycho.nsa.gov>","list_archive_url":null,"date":"2017-09-07T12:32:19","subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","submitter":{"id":410,"url":"http://patchwork.ozlabs.org/api/people/410/","name":"Stephen Smalley","email":"sds@tycho.nsa.gov"},"content":"On Tue, 2017-09-05 at 15:24 -0700, Chenbo Feng via Selinux wrote:\n> On Fri, Sep 1, 2017 at 5:50 AM, Stephen Smalley \n> wrote:\n> > On Thu, 2017-08-31 at 13:56 -0700, Chenbo Feng wrote:\n> > > From: Chenbo Feng \n> > > \n> > > Introduce 5 LSM hooks to provide finer granularity controls on\n> > > eBPF\n> > > related operations including create eBPF maps, modify and read\n> > > eBPF\n> > > maps\n> > > content and load eBPF programs to the kernel. Hooks use the new\n> > > security\n> > > pointer inside the eBPF map struct to store the owner's security\n> > > information and the different security modules can perform\n> > > different\n> > > checks based on the information stored inside the security field.\n> > > \n> > > Signed-off-by: Chenbo Feng \n> > > ---\n> > >  include/linux/lsm_hooks.h | 41\n> > > +++++++++++++++++++++++++++++++++++++++++\n> > >  include/linux/security.h  | 36\n> > > ++++++++++++++++++++++++++++++++++++\n> > >  security/security.c       | 28 ++++++++++++++++++++++++++++\n> > >  3 files changed, 105 insertions(+)\n> > > \n> > > diff --git a/include/linux/lsm_hooks.h\n> > > b/include/linux/lsm_hooks.h\n> > > index ce02f76a6188..3aaf9a08a983 100644\n> > > --- a/include/linux/lsm_hooks.h\n> > > +++ b/include/linux/lsm_hooks.h\n> > > @@ -1353,6 +1353,32 @@\n> > >   *   @inode we wish to get the security context of.\n> > >   *   @ctx is a pointer in which to place the allocated security\n> > > context.\n> > >   *   @ctxlen points to the place to put the length of @ctx.\n> > > + *\n> > > + * Security hooks for using the eBPF maps and programs\n> > > functionalities through\n> > > + * eBPF syscalls.\n> > > + *\n> > > + * @bpf_map_create:\n> > > + *   Check permissions prior to creating a new bpf map.\n> > > + *   Return 0 if the permission is granted.\n> > > + *\n> > > + * @bpf_map_modify:\n> > > + *   Check permission prior to insert, update and delete map\n> > > content.\n> > > + *   @map pointer to the struct bpf_map that contains map\n> > > information.\n> > > + *   Return 0 if the permission is granted.\n> > > + *\n> > > + * @bpf_map_read:\n> > > + *   Check permission prior to read a bpf map content.\n> > > + *   @map pointer to the struct bpf_map that contains map\n> > > information.\n> > > + *   Return 0 if the permission is granted.\n> > > + *\n> > > + * @bpf_prog_load:\n> > > + *   Check permission prior to load eBPF program.\n> > > + *   Return 0 if the permission is granted.\n> > > + *\n> > > + * @bpf_post_create:\n> > > + *   Initialize the bpf object security field inside struct\n> > > bpf_maps and\n> > > + *   it is used for future security checks.\n> > > + *\n> > >   */\n> > >  union security_list_options {\n> > >       int (*binder_set_context_mgr)(struct task_struct *mgr);\n> > > @@ -1685,6 +1711,14 @@ union security_list_options {\n> > >                               struct audit_context *actx);\n> > >       void (*audit_rule_free)(void *lsmrule);\n> > >  #endif /* CONFIG_AUDIT */\n> > > +\n> > > +#ifdef CONFIG_BPF_SYSCALL\n> > > +     int (*bpf_map_create)(void);\n> > > +     int (*bpf_map_read)(struct bpf_map *map);\n> > > +     int (*bpf_map_modify)(struct bpf_map *map);\n> > > +     int (*bpf_prog_load)(void);\n> > > +     int (*bpf_post_create)(struct bpf_map *map);\n> > > +#endif /* CONFIG_BPF_SYSCALL */\n> > >  };\n> > > \n> > >  struct security_hook_heads {\n> > > @@ -1905,6 +1939,13 @@ struct security_hook_heads {\n> > >       struct list_head audit_rule_match;\n> > >       struct list_head audit_rule_free;\n> > >  #endif /* CONFIG_AUDIT */\n> > > +#ifdef CONFIG_BPF_SYSCALL\n> > > +     struct list_head bpf_map_create;\n> > > +     struct list_head bpf_map_read;\n> > > +     struct list_head bpf_map_modify;\n> > > +     struct list_head bpf_prog_load;\n> > > +     struct list_head bpf_post_create;\n> > > +#endif /* CONFIG_BPF_SYSCALL */\n> > >  } __randomize_layout;\n> > > \n> > >  /*\n> > > diff --git a/include/linux/security.h b/include/linux/security.h\n> > > index 458e24bea2d4..0656a4f74d14 100644\n> > > --- a/include/linux/security.h\n> > > +++ b/include/linux/security.h\n> > > @@ -31,6 +31,7 @@\n> > >  #include \n> > >  #include \n> > >  #include \n> > > +#include \n> > > \n> > >  struct linux_binprm;\n> > >  struct cred;\n> > > @@ -1735,6 +1736,41 @@ static inline void\n> > > securityfs_remove(struct\n> > > dentry *dentry)\n> > > \n> > >  #endif\n> > > \n> > > +#ifdef CONFIG_BPF_SYSCALL\n> > > +#ifdef CONFIG_SECURITY\n> > > +int security_map_create(void);\n> > > +int security_map_modify(struct bpf_map *map);\n> > > +int security_map_read(struct bpf_map *map);\n> > > +int security_prog_load(void);\n> > > +int security_post_create(struct bpf_map *map);\n> > > +#else\n> > > +static inline int security_map_create(void)\n> > > +{\n> > > +     return 0;\n> > > +}\n> > > +\n> > > +static inline int security_map_read(struct bpf_map *map)\n> > > +{\n> > > +     return 0;\n> > > +}\n> > > +\n> > > +static inline int security_map_modify(struct bpf_map *map)\n> > > +{\n> > > +     return 0;\n> > > +}\n> > > +\n> > > +static inline int security_prog_load(void)\n> > > +{\n> > > +     return 0;\n> > > +}\n> > > +\n> > > +static inline int security_post_create(struct bpf_map *map)\n> > > +{\n> > > +     return 0;\n> > > +}\n> > > +#endif /* CONFIG_SECURITY */\n> > > +#endif /* CONFIG_BPF_SYSCALL */\n> > \n> > These should be named consistently with the ones in lsm_hooks.h and\n> > should unambiguously indicate that these are hooks for bpf\n> > objects/operations, i.e. security_bpf_map_create(),\n> > security_bpf_map_read(), etc.\n> > \n> \n> Thanks for pointing out, will fix this.\n> > Do you need this level of granularity?\n> > \n> \n> The cover letter of this patch series described a possible use cases\n> of\n> these lsm hooks and this level of granularity would be ideal to reach\n> that\n> goal. We can also implement two hooks such as bpf_obj_create and\n> bpf_obj_use to restrict the creation and using when get the bpf fd\n> from\n> kernel. But that will be less powerful and flexible.\n> > Could you coalesce the map_create() and post_map_create() hooks\n> > into\n> > one hook and just unwind the create in that case?\n> > \n> \n> Okay, I will take a look on how to fix this.\n\nAlso, what you called security_post_create() would normally be called\nsomething like security_bpf_alloc_security(), and would have a\ncorresponding security_bpf_free_security() hook too. However, whether\nor not you still need this security field and hook at all is unclear to\nme, given the direction the discussion has gone.\n\n> > Why do you label bpf maps but not bpf progs?  Should we be\n> > controlling\n> > the ability to attach/detach a bpf prog (partly controlled by\n> > CAP_NET_ADMIN, but also somewhat broad in scope and doesn't allow\n> > control based on who created the prog)?\n> > \n> > Should there be a top-level security_bpf_use() hook and permission\n> > check that limits ability to use bpf() at all?\n> > \n> \n> This could be useful but having additional lsm hooks check when\n> reading\n> and write to eBPF maps may cause performance issue. Instead maybe we\n> could have a hook for creating eBPF object and retrieve object fd to\n> restrict\n> the access.\n> > > +\n> > >  #ifdef CONFIG_SECURITY\n> > > \n> > >  static inline char *alloc_secdata(void)\n> > > diff --git a/security/security.c b/security/security.c\n> > > index 55b5997e4b72..02272f93a89e 100644\n> > > --- a/security/security.c\n> > > +++ b/security/security.c\n> > > @@ -12,6 +12,7 @@\n> > >   *   (at your option) any later version.\n> > >   */\n> > > \n> > > +#include \n> > >  #include \n> > >  #include \n> > >  #include \n> > > @@ -1708,3 +1709,30 @@ int security_audit_rule_match(u32 secid,\n> > > u32\n> > > field, u32 op, void *lsmrule,\n> > >                               actx);\n> > >  }\n> > >  #endif /* CONFIG_AUDIT */\n> > > +\n> > > +#ifdef CONFIG_BPF_SYSCALL\n> > > +int security_map_create(void)\n> > > +{\n> > > +     return call_int_hook(bpf_map_create, 0);\n> > > +}\n> > > +\n> > > +int security_map_modify(struct bpf_map *map)\n> > > +{\n> > > +     return call_int_hook(bpf_map_modify, 0, map);\n> > > +}\n> > > +\n> > > +int security_map_read(struct bpf_map *map)\n> > > +{\n> > > +     return call_int_hook(bpf_map_read, 0, map);\n> > > +}\n> > > +\n> > > +int security_prog_load(void)\n> > > +{\n> > > +     return call_int_hook(bpf_prog_load, 0);\n> > > +}\n> > > +\n> > > +int security_post_create(struct bpf_map *map)\n> > > +{\n> > > +     return call_int_hook(bpf_post_create, 0, map);\n> > > +}\n> > > +#endif /* CONFIG_BPF_SYSCALL */","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xp0Nc3kPyz9s8J\n\tfor ;\n\tThu, 7 Sep 2017 22:38:08 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754958AbdIGMiE (ORCPT );\n\tThu, 7 Sep 2017 08:38:04 -0400","from uphb19pa12.eemsg.mail.mil ([214.24.26.86]:32358 \"EHLO\n\tUSFB19PA15.eemsg.mail.mil\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1754362AbdIGMiD (ORCPT\n\t); Thu, 7 Sep 2017 08:38:03 -0400","from emsm-gh1-uea11.ncsc.mil ([214.29.60.3])\n\tby USFB19PA15.eemsg.mail.mil with ESMTP/TLS/AES256-SHA;\n\t07 Sep 2017 12:28:22 +0000","from unknown (HELO tarius.tycho.ncsc.mil) ([144.51.242.1])\n\tby emsm-gh1-uea11.NCSC.MIL with ESMTP; 07 Sep 2017 12:28:15 +0000","from moss-pluto.infosec.tycho.ncsc.mil (moss-pluto\n\t[192.168.25.131])\n\tby tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v87CRbe4016951;\n\tThu, 7 Sep 2017 08:27:39 -0400"],"X-Greylist":"delayed 579 seconds by postgrey-1.27 at vger.kernel.org;\n\tThu, 07 Sep 2017 08:38:03 EDT","X-IronPort-AV":"E=Sophos;i=\"5.42,358,1500940800\"; d=\"scan'208\";a=\"2003287\"","IronPort-PHdr":"9a23:l/80oBB0cWyL7GfgX++BUyQJP3N1i/DPJgcQr6AfoPdwSP36pc+wAkXT6L1XgUPTWs2DsrQf2rqQ6/iocFdDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZrKeTpAI7SiNm82/yv95HJbQhFgDmwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjDQhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85Kl3VhDnlCYHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6zTZ9MaQXdKUNhXWSJPH4iwa5IDA/QdMepdqYT2ulkAogakBQS0B+3h1z9GiGH406I43eQhFh3J0gsvENwBq3nUsNb4Ob0OXe2v0KXFzzPOZO5W1zfn74jIdwgsr+yQXb1uacrRyVcgFwXYhVuNrIzqJTeV1uATvGmb8uFtUvmvhHM8qwxqvjiuxtsjionOho4PzFDE7j92zJw6Jd2/Vk52eNipG4ZTuSGCL4Z6X8wvTm5ytCs617EKo4C3cScUxJg92hLSbeGMfZKS7RL5TumRJC91hHdieL2imRm/6VOgyujgVsms11ZKszZFnsHMtn8T0xzT7dCKSudn8Ue72DaPyhvT5vtYIUE0iaXbK5khzqQ2lpUPqkTMAjX6mED3jK+Sbkkk++6o5Pr7Yrj+u5OROIB5hhv+P6gzgMCzH+s1PhYUU2SG4ei80afs/Uz9QLVElP02lazZvYjBJcsGva60GBNV04Y/5Ba/CDeqytIYnWIdI15fdxKHiJbpN0nUIP/kFfe/n0iskDBzyvDCOb3hGIvCLn7CkbfmZrt95ElcyA08zdBb+Z1YEK0OIPX2WkXprtzXEgc5MxCow+bgENhyzIceVnyAA6CHMaPeq0SI5v41LOmWY48VpjH9K/k55/7pk380glAdfayz0psWbHC0BOhpI0KcYXD0mNcODX8KvhYiTOztkFCCVT9TZ3CvX6Mz/z07E5ypApveRoC3gbyBwCe6EoRTZmBBF1+MDHPoeJufVvcSZyKdPNVhniYHVbe/UY8h0w+htAvgx7pgNOrU9TUStYj/29ht++3TiRYy+CRoAMSdzW6NSXp7nmQGRzAo2qB/rlZxylSd3qhihfxXC9hT6uhGUgc/L5Hczuh6B8ruVQLGe9eDUEymTcm+ATEtUtIxxMcDY0BjFNW+kx/MwTSqDqQLl7yEGpM06LjQ33vvKMZnzXbJyq0hg0MhQstVOm2snrR/+BTLB47Vj0WZkL6ndaoC0y7L+2eM0XGDvE5fUA53XqXFWW4QalHKotT+40ORB4OpXJ8nPw1LzoasJ61FIonngFNJT9/sP9PRZ2/3kGC1U0Wm3LSJObH2dn0d0SOVM00NlwQe7D7SLgQlLjuwqGLZSjp1HBTgZF26oro2k2+yUkJhl1LCVEZmzbfgv0dP3fE=","X-IPAS-Result":"A2AzBACaOrFZ/wHyM5BcGgEBAQECAQEBAQgBAQEBFQEBAQECAQEBAQgBAQEBgwQrgVIng3eaQjsBAQEBAQEGgSqXWwNchUgChAJXAQEBAQEBAQECAWoogjMkAYJAAQEBAQIBIw8BRhAJAg0IAwICJgICVwYTiA+CFQUIj3mdZoInIgKLJAEBAQEBBQEBAQEBI4ENgh2CAoEHhVKFIYJngmEFoHSUUYITiVgNhnmJfIxoV04/KAoCHwgiD4NugXMcggMkNosKAQEB","Message-ID":"<1504787539.22845.1.camel@tycho.nsa.gov>","Subject":"Re: [PATCH 1/3] security: bpf: Add eBPF LSM hooks to security module","From":"Stephen Smalley ","To":"Chenbo Feng ","Cc":"netdev@vger.kernel.org, Chenbo Feng ,\n\tlinux-security-module@vger.kernel.org, SELinux ,\n\tAlexei Starovoitov ,\n\tLorenzo Colitti ","Date":"Thu, 07 Sep 2017 08:32:19 -0400","In-Reply-To":"","References":"<20170831205635.80256-1-chenbofeng.kernel@gmail.com>\n\t<20170831205635.80256-2-chenbofeng.kernel@gmail.com>\n\t<1504270223.8240.2.camel@tycho.nsa.gov>\n\t","Organization":"National Security Agency","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.6 (3.22.6-2.fc25) ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]