* [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-26 9:46 ` cgel.zte 0 siblings, 0 replies; 58+ messages in thread From: cgel.zte @ 2022-03-26 9:46 UTC (permalink / raw) To: paul, eparis, linux-audit; +Cc: linux-kernel, Yang Yang, Zeal Robot From: Yang Yang <yang.yang29@zte.com.cn> Userspace may use syscall with invalid syscall number by calling syscall(syscall_num,..). For example we found openSSH may use syscall with syscall number is -1 in some case. When that happens we better do a quick handle no need to gohead. Signed-off-by: Yang Yang <yang.yang29@zte.com.cn> Reported-by: Zeal Robot <zealci@zte.com.cn> --- kernel/auditsc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index ea2ee1181921..806cd57d7f20 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2077,7 +2077,8 @@ void __audit_syscall_exit(int success, long return_code) struct audit_context *context = audit_context(); if (!context || context->dummy || - context->context != AUDIT_CTX_SYSCALL) + context->context != AUDIT_CTX_SYSCALL || + unlikely(context->major < 0 || context->major > NR_syscalls)) goto out; /* this may generate CONFIG_CHANGE records */ -- 2.25.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-26 9:46 ` cgel.zte 0 siblings, 0 replies; 58+ messages in thread From: cgel.zte @ 2022-03-26 9:46 UTC (permalink / raw) To: paul, eparis, linux-audit; +Cc: Yang Yang, Zeal Robot, linux-kernel From: Yang Yang <yang.yang29@zte.com.cn> Userspace may use syscall with invalid syscall number by calling syscall(syscall_num,..). For example we found openSSH may use syscall with syscall number is -1 in some case. When that happens we better do a quick handle no need to gohead. Signed-off-by: Yang Yang <yang.yang29@zte.com.cn> Reported-by: Zeal Robot <zealci@zte.com.cn> --- kernel/auditsc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index ea2ee1181921..806cd57d7f20 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2077,7 +2077,8 @@ void __audit_syscall_exit(int success, long return_code) struct audit_context *context = audit_context(); if (!context || context->dummy || - context->context != AUDIT_CTX_SYSCALL) + context->context != AUDIT_CTX_SYSCALL || + unlikely(context->major < 0 || context->major > NR_syscalls)) goto out; /* this may generate CONFIG_CHANGE records */ -- 2.25.1 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-26 9:46 ` cgel.zte @ 2022-03-26 20:55 ` kernel test robot -1 siblings, 0 replies; 58+ messages in thread From: kernel test robot @ 2022-03-26 20:55 UTC (permalink / raw) To: cgel.zte, paul, eparis, linux-audit Cc: kbuild-all, linux-kernel, Yang Yang, Zeal Robot Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on pcmoore-audit/next] [also build test ERROR on v5.17 next-20220325] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220327/202203270449.WBYQF9X3-lkp@intel.com/config) compiler: alpha-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/052b1a11a0bec23358ecc22ad9b085590efd3057 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 git checkout 052b1a11a0bec23358ecc22ad9b085590efd3057 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): In file included from include/linux/init.h:5, from kernel/auditsc.c:34: kernel/auditsc.c: In function '__audit_syscall_exit': >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) | ^~~~~~~~~~~ include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ kernel/auditsc.c:2081:61: note: each undeclared identifier is reported only once for each function it appears in 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) | ^~~~~~~~~~~ include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ vim +2081 kernel/auditsc.c 2063 2064 /** 2065 * __audit_syscall_exit - deallocate audit context after a system call 2066 * @success: success value of the syscall 2067 * @return_code: return value of the syscall 2068 * 2069 * Tear down after system call. If the audit context has been marked as 2070 * auditable (either because of the AUDIT_STATE_RECORD state from 2071 * filtering, or because some other part of the kernel wrote an audit 2072 * message), then write out the syscall information. In call cases, 2073 * free the names stored from getname(). 2074 */ 2075 void __audit_syscall_exit(int success, long return_code) 2076 { 2077 struct audit_context *context = audit_context(); 2078 2079 if (!context || context->dummy || 2080 context->context != AUDIT_CTX_SYSCALL || > 2081 unlikely(context->major < 0 || context->major > NR_syscalls)) 2082 goto out; 2083 2084 /* this may generate CONFIG_CHANGE records */ 2085 if (!list_empty(&context->killed_trees)) 2086 audit_kill_trees(context); 2087 2088 /* run through both filters to ensure we set the filterkey properly */ 2089 audit_filter_syscall(current, context); 2090 audit_filter_inodes(current, context); 2091 if (context->current_state < AUDIT_STATE_RECORD) 2092 goto out; 2093 2094 audit_return_fixup(context, success, return_code); 2095 audit_log_exit(); 2096 2097 out: 2098 audit_reset_context(context); 2099 } 2100 -- 0-DAY CI Kernel Test Service https://01.org/lkp ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-26 20:55 ` kernel test robot 0 siblings, 0 replies; 58+ messages in thread From: kernel test robot @ 2022-03-26 20:55 UTC (permalink / raw) To: cgel.zte, paul, eparis, linux-audit Cc: Yang Yang, Zeal Robot, kbuild-all, linux-kernel Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on pcmoore-audit/next] [also build test ERROR on v5.17 next-20220325] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220327/202203270449.WBYQF9X3-lkp@intel.com/config) compiler: alpha-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/052b1a11a0bec23358ecc22ad9b085590efd3057 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 git checkout 052b1a11a0bec23358ecc22ad9b085590efd3057 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): In file included from include/linux/init.h:5, from kernel/auditsc.c:34: kernel/auditsc.c: In function '__audit_syscall_exit': >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) | ^~~~~~~~~~~ include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ kernel/auditsc.c:2081:61: note: each undeclared identifier is reported only once for each function it appears in 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) | ^~~~~~~~~~~ include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ vim +2081 kernel/auditsc.c 2063 2064 /** 2065 * __audit_syscall_exit - deallocate audit context after a system call 2066 * @success: success value of the syscall 2067 * @return_code: return value of the syscall 2068 * 2069 * Tear down after system call. If the audit context has been marked as 2070 * auditable (either because of the AUDIT_STATE_RECORD state from 2071 * filtering, or because some other part of the kernel wrote an audit 2072 * message), then write out the syscall information. In call cases, 2073 * free the names stored from getname(). 2074 */ 2075 void __audit_syscall_exit(int success, long return_code) 2076 { 2077 struct audit_context *context = audit_context(); 2078 2079 if (!context || context->dummy || 2080 context->context != AUDIT_CTX_SYSCALL || > 2081 unlikely(context->major < 0 || context->major > NR_syscalls)) 2082 goto out; 2083 2084 /* this may generate CONFIG_CHANGE records */ 2085 if (!list_empty(&context->killed_trees)) 2086 audit_kill_trees(context); 2087 2088 /* run through both filters to ensure we set the filterkey properly */ 2089 audit_filter_syscall(current, context); 2090 audit_filter_inodes(current, context); 2091 if (context->current_state < AUDIT_STATE_RECORD) 2092 goto out; 2093 2094 audit_return_fixup(context, success, return_code); 2095 audit_log_exit(); 2096 2097 out: 2098 audit_reset_context(context); 2099 } 2100 -- 0-DAY CI Kernel Test Service https://01.org/lkp -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-26 20:55 ` kernel test robot (?) @ 2022-03-29 1:48 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 1:48 UTC (permalink / raw) To: rth, ink, mattst88, paul Cc: paul, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Sun, Mar 27, 2022 at 04:55:01AM +0800, kernel test robot wrote: > Hi, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on pcmoore-audit/next] > [also build test ERROR on v5.17 next-20220325] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: https://github.com/intel-lab-lkp/linux/commits/cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next > config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220327/202203270449.WBYQF9X3-lkp@intel.com/config) > compiler: alpha-linux-gcc (GCC) 11.2.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://github.com/intel-lab-lkp/linux/commit/052b1a11a0bec23358ecc22ad9b085590efd3057 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > git checkout 052b1a11a0bec23358ecc22ad9b085590efd3057 > # save the config file to linux build tree > mkdir build_dir > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All errors (new ones prefixed by >>): > > In file included from include/linux/init.h:5, > from kernel/auditsc.c:34: > kernel/auditsc.c: In function '__audit_syscall_exit': > >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. I have no alpha environment and not familiar to this arch, much thanks! > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > kernel/auditsc.c:2081:61: note: each undeclared identifier is reported only once for each function it appears in > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > > > vim +2081 kernel/auditsc.c > > 2063 > 2064 /** > 2065 * __audit_syscall_exit - deallocate audit context after a system call > 2066 * @success: success value of the syscall > 2067 * @return_code: return value of the syscall > 2068 * > 2069 * Tear down after system call. If the audit context has been marked as > 2070 * auditable (either because of the AUDIT_STATE_RECORD state from > 2071 * filtering, or because some other part of the kernel wrote an audit > 2072 * message), then write out the syscall information. In call cases, > 2073 * free the names stored from getname(). > 2074 */ > 2075 void __audit_syscall_exit(int success, long return_code) > 2076 { > 2077 struct audit_context *context = audit_context(); > 2078 > 2079 if (!context || context->dummy || > 2080 context->context != AUDIT_CTX_SYSCALL || > > 2081 unlikely(context->major < 0 || context->major > NR_syscalls)) > 2082 goto out; > 2083 > 2084 /* this may generate CONFIG_CHANGE records */ > 2085 if (!list_empty(&context->killed_trees)) > 2086 audit_kill_trees(context); > 2087 > 2088 /* run through both filters to ensure we set the filterkey properly */ > 2089 audit_filter_syscall(current, context); > 2090 audit_filter_inodes(current, context); > 2091 if (context->current_state < AUDIT_STATE_RECORD) > 2092 goto out; > 2093 > 2094 audit_return_fixup(context, success, return_code); > 2095 audit_log_exit(); > 2096 > 2097 out: > 2098 audit_reset_context(context); > 2099 } > 2100 > > -- > 0-DAY CI Kernel Test Service > https://01.org/lkp ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 1:48 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 1:48 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 4757 bytes --] On Sun, Mar 27, 2022 at 04:55:01AM +0800, kernel test robot wrote: > Hi, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on pcmoore-audit/next] > [also build test ERROR on v5.17 next-20220325] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: https://github.com/intel-lab-lkp/linux/commits/cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next > config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220327/202203270449.WBYQF9X3-lkp(a)intel.com/config) > compiler: alpha-linux-gcc (GCC) 11.2.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://github.com/intel-lab-lkp/linux/commit/052b1a11a0bec23358ecc22ad9b085590efd3057 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > git checkout 052b1a11a0bec23358ecc22ad9b085590efd3057 > # save the config file to linux build tree > mkdir build_dir > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All errors (new ones prefixed by >>): > > In file included from include/linux/init.h:5, > from kernel/auditsc.c:34: > kernel/auditsc.c: In function '__audit_syscall_exit': > >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. I have no alpha environment and not familiar to this arch, much thanks! > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > kernel/auditsc.c:2081:61: note: each undeclared identifier is reported only once for each function it appears in > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > > > vim +2081 kernel/auditsc.c > > 2063 > 2064 /** > 2065 * __audit_syscall_exit - deallocate audit context after a system call > 2066 * @success: success value of the syscall > 2067 * @return_code: return value of the syscall > 2068 * > 2069 * Tear down after system call. If the audit context has been marked as > 2070 * auditable (either because of the AUDIT_STATE_RECORD state from > 2071 * filtering, or because some other part of the kernel wrote an audit > 2072 * message), then write out the syscall information. In call cases, > 2073 * free the names stored from getname(). > 2074 */ > 2075 void __audit_syscall_exit(int success, long return_code) > 2076 { > 2077 struct audit_context *context = audit_context(); > 2078 > 2079 if (!context || context->dummy || > 2080 context->context != AUDIT_CTX_SYSCALL || > > 2081 unlikely(context->major < 0 || context->major > NR_syscalls)) > 2082 goto out; > 2083 > 2084 /* this may generate CONFIG_CHANGE records */ > 2085 if (!list_empty(&context->killed_trees)) > 2086 audit_kill_trees(context); > 2087 > 2088 /* run through both filters to ensure we set the filterkey properly */ > 2089 audit_filter_syscall(current, context); > 2090 audit_filter_inodes(current, context); > 2091 if (context->current_state < AUDIT_STATE_RECORD) > 2092 goto out; > 2093 > 2094 audit_return_fixup(context, success, return_code); > 2095 audit_log_exit(); > 2096 > 2097 out: > 2098 audit_reset_context(context); > 2099 } > 2100 > > -- > 0-DAY CI Kernel Test Service > https://01.org/lkp ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 1:48 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 1:48 UTC (permalink / raw) To: rth, ink, mattst88, paul Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit On Sun, Mar 27, 2022 at 04:55:01AM +0800, kernel test robot wrote: > Hi, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on pcmoore-audit/next] > [also build test ERROR on v5.17 next-20220325] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: https://github.com/intel-lab-lkp/linux/commits/cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git next > config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20220327/202203270449.WBYQF9X3-lkp@intel.com/config) > compiler: alpha-linux-gcc (GCC) 11.2.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://github.com/intel-lab-lkp/linux/commit/052b1a11a0bec23358ecc22ad9b085590efd3057 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review cgel-zte-gmail-com/audit-do-a-quick-exit-when-syscall-number-is-invalid/20220326-174904 > git checkout 052b1a11a0bec23358ecc22ad9b085590efd3057 > # save the config file to linux build tree > mkdir build_dir > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=alpha SHELL=/bin/bash > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All errors (new ones prefixed by >>): > > In file included from include/linux/init.h:5, > from kernel/auditsc.c:34: > kernel/auditsc.c: In function '__audit_syscall_exit': > >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. I have no alpha environment and not familiar to this arch, much thanks! > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > kernel/auditsc.c:2081:61: note: each undeclared identifier is reported only once for each function it appears in > 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) > | ^~~~~~~~~~~ > include/linux/compiler.h:78:45: note: in definition of macro 'unlikely' > 78 | # define unlikely(x) __builtin_expect(!!(x), 0) > | ^ > > > vim +2081 kernel/auditsc.c > > 2063 > 2064 /** > 2065 * __audit_syscall_exit - deallocate audit context after a system call > 2066 * @success: success value of the syscall > 2067 * @return_code: return value of the syscall > 2068 * > 2069 * Tear down after system call. If the audit context has been marked as > 2070 * auditable (either because of the AUDIT_STATE_RECORD state from > 2071 * filtering, or because some other part of the kernel wrote an audit > 2072 * message), then write out the syscall information. In call cases, > 2073 * free the names stored from getname(). > 2074 */ > 2075 void __audit_syscall_exit(int success, long return_code) > 2076 { > 2077 struct audit_context *context = audit_context(); > 2078 > 2079 if (!context || context->dummy || > 2080 context->context != AUDIT_CTX_SYSCALL || > > 2081 unlikely(context->major < 0 || context->major > NR_syscalls)) > 2082 goto out; > 2083 > 2084 /* this may generate CONFIG_CHANGE records */ > 2085 if (!list_empty(&context->killed_trees)) > 2086 audit_kill_trees(context); > 2087 > 2088 /* run through both filters to ensure we set the filterkey properly */ > 2089 audit_filter_syscall(current, context); > 2090 audit_filter_inodes(current, context); > 2091 if (context->current_state < AUDIT_STATE_RECORD) > 2092 goto out; > 2093 > 2094 audit_return_fixup(context, success, return_code); > 2095 audit_log_exit(); > 2096 > 2097 out: > 2098 audit_reset_context(context); > 2099 } > 2100 > > -- > 0-DAY CI Kernel Test Service > https://01.org/lkp -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-29 1:48 ` CGEL (?) @ 2022-03-29 2:19 ` Enzo Matsumiya -1 siblings, 0 replies; 58+ messages in thread From: Enzo Matsumiya @ 2022-03-29 2:19 UTC (permalink / raw) To: CGEL Cc: rth, ink, mattst88, paul, kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit On 03/29, CGEL wrote: >> In file included from include/linux/init.h:5, >> from kernel/auditsc.c:34: >> kernel/auditsc.c: In function '__audit_syscall_exit': >> >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? >> 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) >> | ^~~~~~~~~~~ > >Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. >I have no alpha environment and not familiar to this arch, much thanks! Sorry, no experience either, but from a quick look at arch/alpha/include/asm/unistd.h shows that it's called NR_SYSCALLS for alpha arch, for whatever reason. HTH Enzo ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 2:19 ` Enzo Matsumiya 0 siblings, 0 replies; 58+ messages in thread From: Enzo Matsumiya @ 2022-03-29 2:19 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 823 bytes --] On 03/29, CGEL wrote: >> In file included from include/linux/init.h:5, >> from kernel/auditsc.c:34: >> kernel/auditsc.c: In function '__audit_syscall_exit': >> >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? >> 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) >> | ^~~~~~~~~~~ > >Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. >I have no alpha environment and not familiar to this arch, much thanks! Sorry, no experience either, but from a quick look at arch/alpha/include/asm/unistd.h shows that it's called NR_SYSCALLS for alpha arch, for whatever reason. HTH Enzo ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 2:19 ` Enzo Matsumiya 0 siblings, 0 replies; 58+ messages in thread From: Enzo Matsumiya @ 2022-03-29 2:19 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On 03/29, CGEL wrote: >> In file included from include/linux/init.h:5, >> from kernel/auditsc.c:34: >> kernel/auditsc.c: In function '__audit_syscall_exit': >> >> kernel/auditsc.c:2081:61: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? >> 2081 | unlikely(context->major < 0 || context->major > NR_syscalls)) >> | ^~~~~~~~~~~ > >Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. >I have no alpha environment and not familiar to this arch, much thanks! Sorry, no experience either, but from a quick look at arch/alpha/include/asm/unistd.h shows that it's called NR_SYSCALLS for alpha arch, for whatever reason. HTH Enzo -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-29 1:48 ` CGEL (?) @ 2022-03-29 3:06 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 3:06 UTC (permalink / raw) To: CGEL Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > I have no alpha environment and not familiar to this arch, much thanks! Regardless of if this is fixed, I'm not convinced this is something we want to merge. After all, a process executed a syscall and we should process it like any other; just because it happens to be an unrecognized syscall on a particular kernel build doesn't mean it isn't security relevant (probing for specific syscall numbers may be a useful attack fingerprint). -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 3:06 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 3:06 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 621 bytes --] On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > I have no alpha environment and not familiar to this arch, much thanks! Regardless of if this is fixed, I'm not convinced this is something we want to merge. After all, a process executed a syscall and we should process it like any other; just because it happens to be an unrecognized syscall on a particular kernel build doesn't mean it isn't security relevant (probing for specific syscall numbers may be a useful attack fingerprint). -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 3:06 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 3:06 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > I have no alpha environment and not familiar to this arch, much thanks! Regardless of if this is fixed, I'm not convinced this is something we want to merge. After all, a process executed a syscall and we should process it like any other; just because it happens to be an unrecognized syscall on a particular kernel build doesn't mean it isn't security relevant (probing for specific syscall numbers may be a useful attack fingerprint). -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-29 3:06 ` Paul Moore (?) @ 2022-03-29 3:22 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 3:22 UTC (permalink / raw) To: Paul Moore Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > I have no alpha environment and not familiar to this arch, much thanks! > > Regardless of if this is fixed, I'm not convinced this is something we > want to merge. After all, a process executed a syscall and we should > process it like any other; just because it happens to be an > unrecognized syscall on a particular kernel build doesn't mean it > isn't security relevant (probing for specific syscall numbers may be a > useful attack fingerprint). > Thanks for your reply. But syscall number less than 0 is even invalid for auditctl. So we will never hit this kind of audit rule. And invalid syscall number will always cause failure early in syscall handle. sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 Syscall name unknown: -1 > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 3:22 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 3:22 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1002 bytes --] On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > I have no alpha environment and not familiar to this arch, much thanks! > > Regardless of if this is fixed, I'm not convinced this is something we > want to merge. After all, a process executed a syscall and we should > process it like any other; just because it happens to be an > unrecognized syscall on a particular kernel build doesn't mean it > isn't security relevant (probing for specific syscall numbers may be a > useful attack fingerprint). > Thanks for your reply. But syscall number less than 0 is even invalid for auditctl. So we will never hit this kind of audit rule. And invalid syscall number will always cause failure early in syscall handle. sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 Syscall name unknown: -1 > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 3:22 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-29 3:22 UTC (permalink / raw) To: Paul Moore Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > I have no alpha environment and not familiar to this arch, much thanks! > > Regardless of if this is fixed, I'm not convinced this is something we > want to merge. After all, a process executed a syscall and we should > process it like any other; just because it happens to be an > unrecognized syscall on a particular kernel build doesn't mean it > isn't security relevant (probing for specific syscall numbers may be a > useful attack fingerprint). > Thanks for your reply. But syscall number less than 0 is even invalid for auditctl. So we will never hit this kind of audit rule. And invalid syscall number will always cause failure early in syscall handle. sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 Syscall name unknown: -1 > -- > paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-29 3:22 ` CGEL (?) @ 2022-03-29 13:11 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 13:11 UTC (permalink / raw) To: CGEL Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > Regardless of if this is fixed, I'm not convinced this is something we > > want to merge. After all, a process executed a syscall and we should > > process it like any other; just because it happens to be an > > unrecognized syscall on a particular kernel build doesn't mean it > > isn't security relevant (probing for specific syscall numbers may be a > > useful attack fingerprint). > > Thanks for your reply. > > But syscall number less than 0 is even invalid for auditctl. So we > will never hit this kind of audit rule. And invalid syscall number > will always cause failure early in syscall handle. > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > Syscall name unknown: -1 You can add an audit filter without explicitly specifying a syscall: % auditctl -a exit,always -F auid=1000 % auditctl -l -a always,exit -S all -F auid=1000 -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 13:11 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 13:11 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1265 bytes --] On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > Regardless of if this is fixed, I'm not convinced this is something we > > want to merge. After all, a process executed a syscall and we should > > process it like any other; just because it happens to be an > > unrecognized syscall on a particular kernel build doesn't mean it > > isn't security relevant (probing for specific syscall numbers may be a > > useful attack fingerprint). > > Thanks for your reply. > > But syscall number less than 0 is even invalid for auditctl. So we > will never hit this kind of audit rule. And invalid syscall number > will always cause failure early in syscall handle. > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > Syscall name unknown: -1 You can add an audit filter without explicitly specifying a syscall: % auditctl -a exit,always -F auid=1000 % auditctl -l -a always,exit -S all -F auid=1000 -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-29 13:11 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-29 13:11 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > Regardless of if this is fixed, I'm not convinced this is something we > > want to merge. After all, a process executed a syscall and we should > > process it like any other; just because it happens to be an > > unrecognized syscall on a particular kernel build doesn't mean it > > isn't security relevant (probing for specific syscall numbers may be a > > useful attack fingerprint). > > Thanks for your reply. > > But syscall number less than 0 is even invalid for auditctl. So we > will never hit this kind of audit rule. And invalid syscall number > will always cause failure early in syscall handle. > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > Syscall name unknown: -1 You can add an audit filter without explicitly specifying a syscall: % auditctl -a exit,always -F auid=1000 % auditctl -l -a always,exit -S all -F auid=1000 -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-29 13:11 ` Paul Moore (?) @ 2022-03-30 5:59 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-30 5:59 UTC (permalink / raw) To: Paul Moore Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > want to merge. After all, a process executed a syscall and we should > > > process it like any other; just because it happens to be an > > > unrecognized syscall on a particular kernel build doesn't mean it > > > isn't security relevant (probing for specific syscall numbers may be a > > > useful attack fingerprint). > > > > Thanks for your reply. > > > > But syscall number less than 0 is even invalid for auditctl. So we > > will never hit this kind of audit rule. And invalid syscall number > > will always cause failure early in syscall handle. > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > Syscall name unknown: -1 > > You can add an audit filter without explicitly specifying a syscall: > > % auditctl -a exit,always -F auid=1000 > % auditctl -l > -a always,exit -S all -F auid=1000 > I have tried this, and execute program which call syscall number is -1, audit still didn't record it. It supports that there's no need for audit to handle syscall number less than 0. sh-4.2# auditctl -a exit,always sh-4.2# auditctl -l -a always,exit -S all > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-30 5:59 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-30 5:59 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1654 bytes --] On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > want to merge. After all, a process executed a syscall and we should > > > process it like any other; just because it happens to be an > > > unrecognized syscall on a particular kernel build doesn't mean it > > > isn't security relevant (probing for specific syscall numbers may be a > > > useful attack fingerprint). > > > > Thanks for your reply. > > > > But syscall number less than 0 is even invalid for auditctl. So we > > will never hit this kind of audit rule. And invalid syscall number > > will always cause failure early in syscall handle. > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > Syscall name unknown: -1 > > You can add an audit filter without explicitly specifying a syscall: > > % auditctl -a exit,always -F auid=1000 > % auditctl -l > -a always,exit -S all -F auid=1000 > I have tried this, and execute program which call syscall number is -1, audit still didn't record it. It supports that there's no need for audit to handle syscall number less than 0. sh-4.2# auditctl -a exit,always sh-4.2# auditctl -l -a always,exit -S all > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-30 5:59 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-30 5:59 UTC (permalink / raw) To: Paul Moore Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > want to merge. After all, a process executed a syscall and we should > > > process it like any other; just because it happens to be an > > > unrecognized syscall on a particular kernel build doesn't mean it > > > isn't security relevant (probing for specific syscall numbers may be a > > > useful attack fingerprint). > > > > Thanks for your reply. > > > > But syscall number less than 0 is even invalid for auditctl. So we > > will never hit this kind of audit rule. And invalid syscall number > > will always cause failure early in syscall handle. > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > Syscall name unknown: -1 > > You can add an audit filter without explicitly specifying a syscall: > > % auditctl -a exit,always -F auid=1000 > % auditctl -l > -a always,exit -S all -F auid=1000 > I have tried this, and execute program which call syscall number is -1, audit still didn't record it. It supports that there's no need for audit to handle syscall number less than 0. sh-4.2# auditctl -a exit,always sh-4.2# auditctl -l -a always,exit -S all > -- > paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-30 5:59 ` CGEL (?) @ 2022-03-30 14:48 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-30 14:48 UTC (permalink / raw) To: CGEL Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > want to merge. After all, a process executed a syscall and we should > > > > process it like any other; just because it happens to be an > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > useful attack fingerprint). > > > > > > Thanks for your reply. > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > will never hit this kind of audit rule. And invalid syscall number > > > will always cause failure early in syscall handle. > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > Syscall name unknown: -1 > > > > You can add an audit filter without explicitly specifying a syscall: > > > > % auditctl -a exit,always -F auid=1000 > > % auditctl -l > > -a always,exit -S all -F auid=1000 > > > I have tried this, and execute program which call syscall number is -1, > audit still didn't record it. It supports that there's no need for audit > to handle syscall number less than 0. > > sh-4.2# auditctl -a exit,always > sh-4.2# auditctl -l > -a always,exit -S all If audit is not generating SYSCALL records, even for invalid/ENOSYS syscalls, I would consider that a bug which should be fixed. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-30 14:48 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-30 14:48 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1916 bytes --] On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > want to merge. After all, a process executed a syscall and we should > > > > process it like any other; just because it happens to be an > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > useful attack fingerprint). > > > > > > Thanks for your reply. > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > will never hit this kind of audit rule. And invalid syscall number > > > will always cause failure early in syscall handle. > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > Syscall name unknown: -1 > > > > You can add an audit filter without explicitly specifying a syscall: > > > > % auditctl -a exit,always -F auid=1000 > > % auditctl -l > > -a always,exit -S all -F auid=1000 > > > I have tried this, and execute program which call syscall number is -1, > audit still didn't record it. It supports that there's no need for audit > to handle syscall number less than 0. > > sh-4.2# auditctl -a exit,always > sh-4.2# auditctl -l > -a always,exit -S all If audit is not generating SYSCALL records, even for invalid/ENOSYS syscalls, I would consider that a bug which should be fixed. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-30 14:48 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-30 14:48 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, Yang Yang, linux-audit, ink, mattst88, rth On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > want to merge. After all, a process executed a syscall and we should > > > > process it like any other; just because it happens to be an > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > useful attack fingerprint). > > > > > > Thanks for your reply. > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > will never hit this kind of audit rule. And invalid syscall number > > > will always cause failure early in syscall handle. > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > Syscall name unknown: -1 > > > > You can add an audit filter without explicitly specifying a syscall: > > > > % auditctl -a exit,always -F auid=1000 > > % auditctl -l > > -a always,exit -S all -F auid=1000 > > > I have tried this, and execute program which call syscall number is -1, > audit still didn't record it. It supports that there's no need for audit > to handle syscall number less than 0. > > sh-4.2# auditctl -a exit,always > sh-4.2# auditctl -l > -a always,exit -S all If audit is not generating SYSCALL records, even for invalid/ENOSYS syscalls, I would consider that a bug which should be fixed. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-30 14:48 ` Paul Moore (?) @ 2022-03-31 2:29 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-31 2:29 UTC (permalink / raw) To: Paul Moore Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot, guo.xiaofeng, huang.junhua, dai.shixin On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > > want to merge. After all, a process executed a syscall and we should > > > > > process it like any other; just because it happens to be an > > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > > useful attack fingerprint). > > > > > > > > Thanks for your reply. > > > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > > will never hit this kind of audit rule. And invalid syscall number > > > > will always cause failure early in syscall handle. > > > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > > Syscall name unknown: -1 > > > > > > You can add an audit filter without explicitly specifying a syscall: > > > > > > % auditctl -a exit,always -F auid=1000 > > > % auditctl -l > > > -a always,exit -S all -F auid=1000 > > > > > I have tried this, and execute program which call syscall number is -1, > > audit still didn't record it. It supports that there's no need for audit > > to handle syscall number less than 0. > > > > sh-4.2# auditctl -a exit,always > > sh-4.2# auditctl -l > > -a always,exit -S all > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > syscalls, I would consider that a bug which should be fixed. > If we fix this bug, do you think audit invalid/ENOSYS syscalls better be forcible or be a rule that can be configure? I think configure is better. > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-31 2:29 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-31 2:29 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2213 bytes --] On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > > want to merge. After all, a process executed a syscall and we should > > > > > process it like any other; just because it happens to be an > > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > > useful attack fingerprint). > > > > > > > > Thanks for your reply. > > > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > > will never hit this kind of audit rule. And invalid syscall number > > > > will always cause failure early in syscall handle. > > > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > > Syscall name unknown: -1 > > > > > > You can add an audit filter without explicitly specifying a syscall: > > > > > > % auditctl -a exit,always -F auid=1000 > > > % auditctl -l > > > -a always,exit -S all -F auid=1000 > > > > > I have tried this, and execute program which call syscall number is -1, > > audit still didn't record it. It supports that there's no need for audit > > to handle syscall number less than 0. > > > > sh-4.2# auditctl -a exit,always > > sh-4.2# auditctl -l > > -a always,exit -S all > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > syscalls, I would consider that a bug which should be fixed. > If we fix this bug, do you think audit invalid/ENOSYS syscalls better be forcible or be a rule that can be configure? I think configure is better. > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-31 2:29 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-03-31 2:29 UTC (permalink / raw) To: Paul Moore Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88, rth On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 1:59 AM CGEL <cgel.zte@gmail.com> wrote: > > On Tue, Mar 29, 2022 at 09:11:19AM -0400, Paul Moore wrote: > > > On Mon, Mar 28, 2022 at 11:22 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Mon, Mar 28, 2022 at 11:06:12PM -0400, Paul Moore wrote: > > > > > On Mon, Mar 28, 2022 at 9:48 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > Sorry could anybody give a hand to solve this? It works well on x86_64 and arm64. > > > > > > I have no alpha environment and not familiar to this arch, much thanks! > > > > > > > > > > Regardless of if this is fixed, I'm not convinced this is something we > > > > > want to merge. After all, a process executed a syscall and we should > > > > > process it like any other; just because it happens to be an > > > > > unrecognized syscall on a particular kernel build doesn't mean it > > > > > isn't security relevant (probing for specific syscall numbers may be a > > > > > useful attack fingerprint). > > > > > > > > Thanks for your reply. > > > > > > > > But syscall number less than 0 is even invalid for auditctl. So we > > > > will never hit this kind of audit rule. And invalid syscall number > > > > will always cause failure early in syscall handle. > > > > > > > > sh-4.2# auditctl -a always,exit -F arch=b64 -S -1 > > > > Syscall name unknown: -1 > > > > > > You can add an audit filter without explicitly specifying a syscall: > > > > > > % auditctl -a exit,always -F auid=1000 > > > % auditctl -l > > > -a always,exit -S all -F auid=1000 > > > > > I have tried this, and execute program which call syscall number is -1, > > audit still didn't record it. It supports that there's no need for audit > > to handle syscall number less than 0. > > > > sh-4.2# auditctl -a exit,always > > sh-4.2# auditctl -l > > -a always,exit -S all > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > syscalls, I would consider that a bug which should be fixed. > If we fix this bug, do you think audit invalid/ENOSYS syscalls better be forcible or be a rule that can be configure? I think configure is better. > -- > paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-31 2:29 ` CGEL (?) @ 2022-03-31 14:16 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-31 14:16 UTC (permalink / raw) To: CGEL Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot, guo.xiaofeng, huang.junhua, dai.shixin On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > syscalls, I would consider that a bug which should be fixed. > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > be forcible or be a rule that can be configure? I think configure is > better. It isn't clear to me exactly what you are asking, but I would expect the existing audit syscall filtering mechanism to work regardless if the syscall is valid or not. Beware that there are some limitations to the audit syscall filter, which are unfortunately baked into the current design/implementation, which may affect this to some extent. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-31 14:16 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-31 14:16 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 805 bytes --] On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > syscalls, I would consider that a bug which should be fixed. > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > be forcible or be a rule that can be configure? I think configure is > better. It isn't clear to me exactly what you are asking, but I would expect the existing audit syscall filtering mechanism to work regardless if the syscall is valid or not. Beware that there are some limitations to the audit syscall filter, which are unfortunately baked into the current design/implementation, which may affect this to some extent. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-03-31 14:16 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-03-31 14:16 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88, rth On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > syscalls, I would consider that a bug which should be fixed. > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > be forcible or be a rule that can be configure? I think configure is > better. It isn't clear to me exactly what you are asking, but I would expect the existing audit syscall filtering mechanism to work regardless if the syscall is valid or not. Beware that there are some limitations to the audit syscall filter, which are unfortunately baked into the current design/implementation, which may affect this to some extent. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-03-31 14:16 ` Paul Moore (?) @ 2022-04-01 1:57 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-01 1:57 UTC (permalink / raw) To: Paul Moore Cc: rth, ink, mattst88, eparis, linux-audit, kbuild-all, linux-kernel, Yang Yang, Zeal Robot, guo.xiaofeng, huang.junhua, dai.shixin On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > syscalls, I would consider that a bug which should be fixed. > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > be forcible or be a rule that can be configure? I think configure is > > better. > > It isn't clear to me exactly what you are asking, but I would expect > the existing audit syscall filtering mechanism to work regardless if > the syscall is valid or not. Thanks, I try to make it more clear. We found that auditctl would only set rule with syscall number (>=0 && <2047). So if userspace using syscall whose number is (<0 || >=2047), there seems no meaning for kernel audit to handle it, since this kind of syscall will never hit any audit rule(this rule could not be set by auditctl). By the way it's a little strange for auditctl(using libaudit.c) to limit syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially we know NR_syscalls is the real limit in kernel, you can see how other kernel code to the similar thing in ftrace_syscall_enter(): static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id) { ... syscall_nr = trace_get_syscall_nr(current, regs); if (syscall_nr < 0 || syscall_nr >= NR_syscalls) return; ... } Thanks. > Beware that there are some limitations > to the audit syscall filter, which are unfortunately baked into the > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 1:57 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-01 1:57 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1758 bytes --] On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > syscalls, I would consider that a bug which should be fixed. > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > be forcible or be a rule that can be configure? I think configure is > > better. > > It isn't clear to me exactly what you are asking, but I would expect > the existing audit syscall filtering mechanism to work regardless if > the syscall is valid or not. Thanks, I try to make it more clear. We found that auditctl would only set rule with syscall number (>=0 && <2047). So if userspace using syscall whose number is (<0 || >=2047), there seems no meaning for kernel audit to handle it, since this kind of syscall will never hit any audit rule(this rule could not be set by auditctl). By the way it's a little strange for auditctl(using libaudit.c) to limit syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially we know NR_syscalls is the real limit in kernel, you can see how other kernel code to the similar thing in ftrace_syscall_enter(): static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id) { ... syscall_nr = trace_get_syscall_nr(current, regs); if (syscall_nr < 0 || syscall_nr >= NR_syscalls) return; ... } Thanks. > Beware that there are some limitations > to the audit syscall filter, which are unfortunately baked into the > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 1:57 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-01 1:57 UTC (permalink / raw) To: Paul Moore Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88, rth On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > syscalls, I would consider that a bug which should be fixed. > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > be forcible or be a rule that can be configure? I think configure is > > better. > > It isn't clear to me exactly what you are asking, but I would expect > the existing audit syscall filtering mechanism to work regardless if > the syscall is valid or not. Thanks, I try to make it more clear. We found that auditctl would only set rule with syscall number (>=0 && <2047). So if userspace using syscall whose number is (<0 || >=2047), there seems no meaning for kernel audit to handle it, since this kind of syscall will never hit any audit rule(this rule could not be set by auditctl). By the way it's a little strange for auditctl(using libaudit.c) to limit syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially we know NR_syscalls is the real limit in kernel, you can see how other kernel code to the similar thing in ftrace_syscall_enter(): static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id) { ... syscall_nr = trace_get_syscall_nr(current, regs); if (syscall_nr < 0 || syscall_nr >= NR_syscalls) return; ... } Thanks. > Beware that there are some limitations > to the audit syscall filter, which are unfortunately baked into the > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-01 1:57 ` CGEL (?) @ 2022-04-01 13:39 ` Steve Grubb -1 siblings, 0 replies; 58+ messages in thread From: Steve Grubb @ 2022-04-01 13:39 UTC (permalink / raw) To: Paul Moore, linux-audit, CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > be forcible or be a rule that can be configure? I think configure is > > > better. > > > > It isn't clear to me exactly what you are asking, but I would expect > > the existing audit syscall filtering mechanism to work regardless if > > the syscall is valid or not. > > Thanks, I try to make it more clear. We found that auditctl would only > set rule with syscall number (>=0 && <2047). So if userspace using > syscall whose number is (<0 || >=2047), there seems no meaning for > kernel audit to handle it, since this kind of syscall will never hit > any audit rule(this rule could not be set by auditctl). This limit is imposed by: /usr/include/linux/audit.h struct audit_rule_data { ... __u32 mask[AUDIT_BITMASK_SIZE]; /* syscall(s) affected */ Where #define AUDIT_BITMASK_SIZE 64 So, 64 * 32 = 2048 -Steve > By the way it's a little strange for auditctl(using libaudit.c) to limit > syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially > we know NR_syscalls is the real limit in kernel, you can see how other > kernel code to the similar thing in ftrace_syscall_enter(): > > static void ftrace_syscall_enter(void *data, struct pt_regs > *regs, long id) > { > ... > syscall_nr = trace_get_syscall_nr(current, regs); > if (syscall_nr < 0 || syscall_nr >= NR_syscalls) > return; > ... > } > > Thanks. > > > Beware that there are some limitations > > to the audit syscall filter, which are unfortunately baked into the > > current design/implementation, which may affect this to some extent. > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 13:39 ` Steve Grubb 0 siblings, 0 replies; 58+ messages in thread From: Steve Grubb @ 2022-04-01 13:39 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2232 bytes --] On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > be forcible or be a rule that can be configure? I think configure is > > > better. > > > > It isn't clear to me exactly what you are asking, but I would expect > > the existing audit syscall filtering mechanism to work regardless if > > the syscall is valid or not. > > Thanks, I try to make it more clear. We found that auditctl would only > set rule with syscall number (>=0 && <2047). So if userspace using > syscall whose number is (<0 || >=2047), there seems no meaning for > kernel audit to handle it, since this kind of syscall will never hit > any audit rule(this rule could not be set by auditctl). This limit is imposed by: /usr/include/linux/audit.h struct audit_rule_data { ... __u32 mask[AUDIT_BITMASK_SIZE]; /* syscall(s) affected */ Where #define AUDIT_BITMASK_SIZE 64 So, 64 * 32 = 2048 -Steve > By the way it's a little strange for auditctl(using libaudit.c) to limit > syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially > we know NR_syscalls is the real limit in kernel, you can see how other > kernel code to the similar thing in ftrace_syscall_enter(): > > static void ftrace_syscall_enter(void *data, struct pt_regs > *regs, long id) > { > ... > syscall_nr = trace_get_syscall_nr(current, regs); > if (syscall_nr < 0 || syscall_nr >= NR_syscalls) > return; > ... > } > > Thanks. > > > Beware that there are some limitations > > to the audit syscall filter, which are unfortunately baked into the > > current design/implementation, which may affect this to some extent. > > -- > Linux-audit mailing list > Linux-audit(a)redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 13:39 ` Steve Grubb 0 siblings, 0 replies; 58+ messages in thread From: Steve Grubb @ 2022-04-01 13:39 UTC (permalink / raw) To: Paul Moore, linux-audit, CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > be forcible or be a rule that can be configure? I think configure is > > > better. > > > > It isn't clear to me exactly what you are asking, but I would expect > > the existing audit syscall filtering mechanism to work regardless if > > the syscall is valid or not. > > Thanks, I try to make it more clear. We found that auditctl would only > set rule with syscall number (>=0 && <2047). So if userspace using > syscall whose number is (<0 || >=2047), there seems no meaning for > kernel audit to handle it, since this kind of syscall will never hit > any audit rule(this rule could not be set by auditctl). This limit is imposed by: /usr/include/linux/audit.h struct audit_rule_data { ... __u32 mask[AUDIT_BITMASK_SIZE]; /* syscall(s) affected */ Where #define AUDIT_BITMASK_SIZE 64 So, 64 * 32 = 2048 -Steve > By the way it's a little strange for auditctl(using libaudit.c) to limit > syscall number (>=0 && <2047)(see audit_rule_syscall_data()), especially > we know NR_syscalls is the real limit in kernel, you can see how other > kernel code to the similar thing in ftrace_syscall_enter(): > > static void ftrace_syscall_enter(void *data, struct pt_regs > *regs, long id) > { > ... > syscall_nr = trace_get_syscall_nr(current, regs); > if (syscall_nr < 0 || syscall_nr >= NR_syscalls) > return; > ... > } > > Thanks. > > > Beware that there are some limitations > > to the audit syscall filter, which are unfortunately baked into the > > current design/implementation, which may affect this to some extent. > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-01 13:39 ` Steve Grubb (?) @ 2022-04-01 14:16 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-01 14:16 UTC (permalink / raw) To: Steve Grubb Cc: linux-audit, CGEL, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, ink, huang.junhua, guo.xiaofeng, mattst88 On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > be forcible or be a rule that can be configure? I think configure is > > > > better. > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > the existing audit syscall filtering mechanism to work regardless if > > > the syscall is valid or not. > > > > Thanks, I try to make it more clear. We found that auditctl would only > > set rule with syscall number (>=0 && <2047) ... That is exactly why I wrote the warning below in my response ... > > > Beware that there are some limitations > > > to the audit syscall filter, which are unfortunately baked into the > > > current design/implementation, which may affect this to some extent. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 14:16 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-01 14:16 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 1290 bytes --] On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > be forcible or be a rule that can be configure? I think configure is > > > > better. > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > the existing audit syscall filtering mechanism to work regardless if > > > the syscall is valid or not. > > > > Thanks, I try to make it more clear. We found that auditctl would only > > set rule with syscall number (>=0 && <2047) ... That is exactly why I wrote the warning below in my response ... > > > Beware that there are some limitations > > > to the audit syscall filter, which are unfortunately baked into the > > > current design/implementation, which may affect this to some extent. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-01 14:16 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-01 14:16 UTC (permalink / raw) To: Steve Grubb Cc: kbuild-all, CGEL, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > be forcible or be a rule that can be configure? I think configure is > > > > better. > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > the existing audit syscall filtering mechanism to work regardless if > > > the syscall is valid or not. > > > > Thanks, I try to make it more clear. We found that auditctl would only > > set rule with syscall number (>=0 && <2047) ... That is exactly why I wrote the warning below in my response ... > > > Beware that there are some limitations > > > to the audit syscall filter, which are unfortunately baked into the > > > current design/implementation, which may affect this to some extent. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-01 14:16 ` Paul Moore (?) @ 2022-04-02 8:06 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-02 8:06 UTC (permalink / raw) To: Paul Moore Cc: Steve Grubb, linux-audit, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, ink, huang.junhua, guo.xiaofeng, mattst88 On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > better. > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > the existing audit syscall filtering mechanism to work regardless if > > > > the syscall is valid or not. > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > set rule with syscall number (>=0 && <2047) ... > > That is exactly why I wrote the warning below in my response ... > I think the question is more clear now. 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and syscall with number 3000 are both invalid syscall. But 2000 can be set by auditctl, and 3000 cannot be set by auditctl. A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall See this patch. If we want audit invalid syscall as you said before. libaudit.c should not do the forbidden, auditctl should allow setting syscall rule with 'any' number. So do you think we should fix libaudit.c? > > > > Beware that there are some limitations > > > > to the audit syscall filter, which are unfortunately baked into the > > > > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-02 8:06 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-02 8:06 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2101 bytes --] On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > better. > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > the existing audit syscall filtering mechanism to work regardless if > > > > the syscall is valid or not. > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > set rule with syscall number (>=0 && <2047) ... > > That is exactly why I wrote the warning below in my response ... > I think the question is more clear now. 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and syscall with number 3000 are both invalid syscall. But 2000 can be set by auditctl, and 3000 cannot be set by auditctl. A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall See this patch. If we want audit invalid syscall as you said before. libaudit.c should not do the forbidden, auditctl should allow setting syscall rule with 'any' number. So do you think we should fix libaudit.c? > > > > Beware that there are some limitations > > > > to the audit syscall filter, which are unfortunately baked into the > > > > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-02 8:06 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-02 8:06 UTC (permalink / raw) To: Paul Moore Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > better. > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > the existing audit syscall filtering mechanism to work regardless if > > > > the syscall is valid or not. > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > set rule with syscall number (>=0 && <2047) ... > > That is exactly why I wrote the warning below in my response ... > I think the question is more clear now. 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and syscall with number 3000 are both invalid syscall. But 2000 can be set by auditctl, and 3000 cannot be set by auditctl. A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall See this patch. If we want audit invalid syscall as you said before. libaudit.c should not do the forbidden, auditctl should allow setting syscall rule with 'any' number. So do you think we should fix libaudit.c? > > > > Beware that there are some limitations > > > > to the audit syscall filter, which are unfortunately baked into the > > > > current design/implementation, which may affect this to some extent. > > -- > paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-02 8:06 ` CGEL (?) @ 2022-04-02 15:07 ` Paul Moore -1 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-02 15:07 UTC (permalink / raw) To: CGEL Cc: Steve Grubb, linux-audit, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, ink, huang.junhua, guo.xiaofeng, mattst88 On Sat, Apr 2, 2022 at 4:06 AM CGEL <cgel.zte@gmail.com> wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm really not very clear on what you are proposing, but we can't change the kernel/userspace API in any way which would break compatibility with old/existing userspace tools. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-02 15:07 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-02 15:07 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2208 bytes --] On Sat, Apr 2, 2022 at 4:06 AM CGEL <cgel.zte@gmail.com> wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm really not very clear on what you are proposing, but we can't change the kernel/userspace API in any way which would break compatibility with old/existing userspace tools. -- paul-moore.com ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-02 15:07 ` Paul Moore 0 siblings, 0 replies; 58+ messages in thread From: Paul Moore @ 2022-04-02 15:07 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Sat, Apr 2, 2022 at 4:06 AM CGEL <cgel.zte@gmail.com> wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm really not very clear on what you are proposing, but we can't change the kernel/userspace API in any way which would break compatibility with old/existing userspace tools. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-02 8:06 ` CGEL (?) @ 2022-04-04 15:58 ` Richard Guy Briggs -1 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-04 15:58 UTC (permalink / raw) To: CGEL Cc: Paul Moore, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On 2022-04-02 08:06, CGEL wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm having a bit of trouble understanding what you've said above. The kernel ultimately must protect itself from malice and mistakes, so it must verify all data sent to it. Userspace can help by knowing what that kernel policy is so it can avoid violating that policy or provide useful feedback if it can't. Userspace can be used to make things more efficient, but the kernel is the last step for security. If userspace and the kernel are mismatched or out of sync, then the kernel enforces policy to protect itself. > > > > > Beware that there are some limitations > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > current design/implementation, which may affect this to some extent. > > > > -- > > paul-moore.com - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-04 15:58 ` Richard Guy Briggs 0 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-04 15:58 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2963 bytes --] On 2022-04-02 08:06, CGEL wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm having a bit of trouble understanding what you've said above. The kernel ultimately must protect itself from malice and mistakes, so it must verify all data sent to it. Userspace can help by knowing what that kernel policy is so it can avoid violating that policy or provide useful feedback if it can't. Userspace can be used to make things more efficient, but the kernel is the last step for security. If userspace and the kernel are mismatched or out of sync, then the kernel enforces policy to protect itself. > > > > > Beware that there are some limitations > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > current design/implementation, which may affect this to some extent. > > > > -- > > paul-moore.com - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-04 15:58 ` Richard Guy Briggs 0 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-04 15:58 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On 2022-04-02 08:06, CGEL wrote: > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > better. > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > the syscall is valid or not. > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > set rule with syscall number (>=0 && <2047) ... > > > > That is exactly why I wrote the warning below in my response ... > > > I think the question is more clear now. > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > syscall with number 3000 are both invalid syscall. But 2000 can be set by > auditctl, and 3000 cannot be set by auditctl. > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > See this patch. > > If we want audit invalid syscall as you said before. libaudit.c should not > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > So do you think we should fix libaudit.c? I'm having a bit of trouble understanding what you've said above. The kernel ultimately must protect itself from malice and mistakes, so it must verify all data sent to it. Userspace can help by knowing what that kernel policy is so it can avoid violating that policy or provide useful feedback if it can't. Userspace can be used to make things more efficient, but the kernel is the last step for security. If userspace and the kernel are mismatched or out of sync, then the kernel enforces policy to protect itself. > > > > > Beware that there are some limitations > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > current design/implementation, which may affect this to some extent. > > > > -- > > paul-moore.com - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-04 15:58 ` Richard Guy Briggs (?) @ 2022-04-06 1:19 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-06 1:19 UTC (permalink / raw) To: Richard Guy Briggs Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > On 2022-04-02 08:06, CGEL wrote: > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > better. > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > the syscall is valid or not. > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > I think the question is more clear now. > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > auditctl, and 3000 cannot be set by auditctl. > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > See this patch. > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > So do you think we should fix libaudit.c? > > I'm having a bit of trouble understanding what you've said above. > > The kernel ultimately must protect itself from malice and mistakes, so > it must verify all data sent to it. > > Userspace can help by knowing what that kernel policy is so it can avoid > violating that policy or provide useful feedback if it can't. Userspace > can be used to make things more efficient, but the kernel is the last > step for security. > > If userspace and the kernel are mismatched or out of sync, then the > kernel enforces policy to protect itself. > Much appreciate for your interpretation. Have you get any idea of how to solve the mismatched? From your viewpoint, I think it's better for kernel to not handle syscall of syscall number<0, because it's invaild of all arch, and has no value for attacker to probing for specific syscall numbers. > > > > > > Beware that there are some limitations > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > current design/implementation, which may affect this to some extent. > > > > > > -- > > > paul-moore.com > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-06 1:19 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-06 1:19 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 3461 bytes --] On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > On 2022-04-02 08:06, CGEL wrote: > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > better. > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > the syscall is valid or not. > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > I think the question is more clear now. > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > auditctl, and 3000 cannot be set by auditctl. > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > See this patch. > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > So do you think we should fix libaudit.c? > > I'm having a bit of trouble understanding what you've said above. > > The kernel ultimately must protect itself from malice and mistakes, so > it must verify all data sent to it. > > Userspace can help by knowing what that kernel policy is so it can avoid > violating that policy or provide useful feedback if it can't. Userspace > can be used to make things more efficient, but the kernel is the last > step for security. > > If userspace and the kernel are mismatched or out of sync, then the > kernel enforces policy to protect itself. > Much appreciate for your interpretation. Have you get any idea of how to solve the mismatched? From your viewpoint, I think it's better for kernel to not handle syscall of syscall number<0, because it's invaild of all arch, and has no value for attacker to probing for specific syscall numbers. > > > > > > Beware that there are some limitations > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > current design/implementation, which may affect this to some extent. > > > > > > -- > > > paul-moore.com > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-06 1:19 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-06 1:19 UTC (permalink / raw) To: Richard Guy Briggs Cc: Paul Moore, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > On 2022-04-02 08:06, CGEL wrote: > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > better. > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > the syscall is valid or not. > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > I think the question is more clear now. > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > auditctl, and 3000 cannot be set by auditctl. > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > See this patch. > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > So do you think we should fix libaudit.c? > > I'm having a bit of trouble understanding what you've said above. > > The kernel ultimately must protect itself from malice and mistakes, so > it must verify all data sent to it. > > Userspace can help by knowing what that kernel policy is so it can avoid > violating that policy or provide useful feedback if it can't. Userspace > can be used to make things more efficient, but the kernel is the last > step for security. > > If userspace and the kernel are mismatched or out of sync, then the > kernel enforces policy to protect itself. > Much appreciate for your interpretation. Have you get any idea of how to solve the mismatched? From your viewpoint, I think it's better for kernel to not handle syscall of syscall number<0, because it's invaild of all arch, and has no value for attacker to probing for specific syscall numbers. > > > > > > Beware that there are some limitations > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > current design/implementation, which may affect this to some extent. > > > > > > -- > > > paul-moore.com > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-06 1:19 ` CGEL (?) @ 2022-04-06 16:49 ` Richard Guy Briggs -1 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-06 16:49 UTC (permalink / raw) To: CGEL Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On 2022-04-06 01:19, CGEL wrote: > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > On 2022-04-02 08:06, CGEL wrote: > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > better. > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > the syscall is valid or not. > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > I think the question is more clear now. > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > auditctl, and 3000 cannot be set by auditctl. > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > See this patch. > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > So do you think we should fix libaudit.c? > > > > I'm having a bit of trouble understanding what you've said above. > > > > The kernel ultimately must protect itself from malice and mistakes, so > > it must verify all data sent to it. > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > violating that policy or provide useful feedback if it can't. Userspace > > can be used to make things more efficient, but the kernel is the last > > step for security. > > > > If userspace and the kernel are mismatched or out of sync, then the > > kernel enforces policy to protect itself. > > Much appreciate for your interpretation. Have you get any idea of how > to solve the mismatched? From your viewpoint, I think it's better for > kernel to not handle syscall of syscall number<0, because it's invaild > of all arch, and has no value for attacker to probing for specific > syscall numbers. Going back to the very first quoted line above, if you can generate a test case that shows that audit is missing an auditable event, that is a bug that should be fixed. > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > -- > > > > paul-moore.com > > > > - RGB - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-06 16:49 ` Richard Guy Briggs 0 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-06 16:49 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 3742 bytes --] On 2022-04-06 01:19, CGEL wrote: > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > On 2022-04-02 08:06, CGEL wrote: > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > better. > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > the syscall is valid or not. > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > I think the question is more clear now. > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > auditctl, and 3000 cannot be set by auditctl. > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > See this patch. > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > So do you think we should fix libaudit.c? > > > > I'm having a bit of trouble understanding what you've said above. > > > > The kernel ultimately must protect itself from malice and mistakes, so > > it must verify all data sent to it. > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > violating that policy or provide useful feedback if it can't. Userspace > > can be used to make things more efficient, but the kernel is the last > > step for security. > > > > If userspace and the kernel are mismatched or out of sync, then the > > kernel enforces policy to protect itself. > > Much appreciate for your interpretation. Have you get any idea of how > to solve the mismatched? From your viewpoint, I think it's better for > kernel to not handle syscall of syscall number<0, because it's invaild > of all arch, and has no value for attacker to probing for specific > syscall numbers. Going back to the very first quoted line above, if you can generate a test case that shows that audit is missing an auditable event, that is a bug that should be fixed. > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > -- > > > > paul-moore.com > > > > - RGB - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-06 16:49 ` Richard Guy Briggs 0 siblings, 0 replies; 58+ messages in thread From: Richard Guy Briggs @ 2022-04-06 16:49 UTC (permalink / raw) To: CGEL Cc: Paul Moore, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On 2022-04-06 01:19, CGEL wrote: > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > On 2022-04-02 08:06, CGEL wrote: > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > better. > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > the syscall is valid or not. > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > I think the question is more clear now. > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > auditctl, and 3000 cannot be set by auditctl. > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > See this patch. > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > So do you think we should fix libaudit.c? > > > > I'm having a bit of trouble understanding what you've said above. > > > > The kernel ultimately must protect itself from malice and mistakes, so > > it must verify all data sent to it. > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > violating that policy or provide useful feedback if it can't. Userspace > > can be used to make things more efficient, but the kernel is the last > > step for security. > > > > If userspace and the kernel are mismatched or out of sync, then the > > kernel enforces policy to protect itself. > > Much appreciate for your interpretation. Have you get any idea of how > to solve the mismatched? From your viewpoint, I think it's better for > kernel to not handle syscall of syscall number<0, because it's invaild > of all arch, and has no value for attacker to probing for specific > syscall numbers. Going back to the very first quoted line above, if you can generate a test case that shows that audit is missing an auditable event, that is a bug that should be fixed. > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > -- > > > > paul-moore.com > > > > - RGB - RGB -- Richard Guy Briggs <rgb@redhat.com> Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid 2022-04-06 16:49 ` Richard Guy Briggs (?) @ 2022-04-07 2:36 ` CGEL -1 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-07 2:36 UTC (permalink / raw) To: Richard Guy Briggs Cc: Paul Moore, kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Wed, Apr 06, 2022 at 12:49:54PM -0400, Richard Guy Briggs wrote: > On 2022-04-06 01:19, CGEL wrote: > > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > > On 2022-04-02 08:06, CGEL wrote: > > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > > better. > > > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > > the syscall is valid or not. > > > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > > > I think the question is more clear now. > > > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > > auditctl, and 3000 cannot be set by auditctl. > > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > > See this patch. > > > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > > So do you think we should fix libaudit.c? > > > > > > I'm having a bit of trouble understanding what you've said above. > > > > > > The kernel ultimately must protect itself from malice and mistakes, so > > > it must verify all data sent to it. > > > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > > violating that policy or provide useful feedback if it can't. Userspace > > > can be used to make things more efficient, but the kernel is the last > > > step for security. > > > > > > If userspace and the kernel are mismatched or out of sync, then the > > > kernel enforces policy to protect itself. > > > > Much appreciate for your interpretation. Have you get any idea of how > > to solve the mismatched? From your viewpoint, I think it's better for > > kernel to not handle syscall of syscall number<0, because it's invaild > > of all arch, and has no value for attacker to probing for specific > > syscall numbers. > > Going back to the very first quoted line above, if you can generate a > test case that shows that audit is missing an auditable event, that is a > bug that should be fixed. > To reproduce "missing auditing invalid syscall": 1.add audit rule auditctl -a always,exit -F arch=b64 -S all 2.run program with invalid syscalls Code as below. Both syscall can not be audited. #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <sys/time.h> #include <sys/stat.h> #include <sys/syscall.h> #include <fcntl.h> #include <errno.h> int main(int argc, char * argv[]) { int syscall_num = -1; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); syscall_num = 3000; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); return 1; } > > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > > > -- > > > > > paul-moore.com > > > > > > - RGB > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-07 2:36 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-07 2:36 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 4739 bytes --] On Wed, Apr 06, 2022 at 12:49:54PM -0400, Richard Guy Briggs wrote: > On 2022-04-06 01:19, CGEL wrote: > > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > > On 2022-04-02 08:06, CGEL wrote: > > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > > better. > > > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > > the syscall is valid or not. > > > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > > > I think the question is more clear now. > > > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > > auditctl, and 3000 cannot be set by auditctl. > > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > > See this patch. > > > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > > So do you think we should fix libaudit.c? > > > > > > I'm having a bit of trouble understanding what you've said above. > > > > > > The kernel ultimately must protect itself from malice and mistakes, so > > > it must verify all data sent to it. > > > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > > violating that policy or provide useful feedback if it can't. Userspace > > > can be used to make things more efficient, but the kernel is the last > > > step for security. > > > > > > If userspace and the kernel are mismatched or out of sync, then the > > > kernel enforces policy to protect itself. > > > > Much appreciate for your interpretation. Have you get any idea of how > > to solve the mismatched? From your viewpoint, I think it's better for > > kernel to not handle syscall of syscall number<0, because it's invaild > > of all arch, and has no value for attacker to probing for specific > > syscall numbers. > > Going back to the very first quoted line above, if you can generate a > test case that shows that audit is missing an auditable event, that is a > bug that should be fixed. > To reproduce "missing auditing invalid syscall": 1.add audit rule auditctl -a always,exit -F arch=b64 -S all 2.run program with invalid syscalls Code as below. Both syscall can not be audited. #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <sys/time.h> #include <sys/stat.h> #include <sys/syscall.h> #include <fcntl.h> #include <errno.h> int main(int argc, char * argv[]) { int syscall_num = -1; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); syscall_num = 3000; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); return 1; } > > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > > > -- > > > > > paul-moore.com > > > > > > - RGB > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH] audit: do a quick exit when syscall number is invalid @ 2022-04-07 2:36 ` CGEL 0 siblings, 0 replies; 58+ messages in thread From: CGEL @ 2022-04-07 2:36 UTC (permalink / raw) To: Richard Guy Briggs Cc: kbuild-all, Zeal Robot, linux-kernel, eparis, dai.shixin, Yang Yang, linux-audit, ink, huang.junhua, guo.xiaofeng, mattst88 On Wed, Apr 06, 2022 at 12:49:54PM -0400, Richard Guy Briggs wrote: > On 2022-04-06 01:19, CGEL wrote: > > On Mon, Apr 04, 2022 at 11:58:50AM -0400, Richard Guy Briggs wrote: > > > On 2022-04-02 08:06, CGEL wrote: > > > > On Fri, Apr 01, 2022 at 10:16:45AM -0400, Paul Moore wrote: > > > > > On Fri, Apr 1, 2022 at 9:39 AM Steve Grubb <sgrubb@redhat.com> wrote: > > > > > > On Thursday, March 31, 2022 9:57:05 PM EDT CGEL wrote: > > > > > > > On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > > > > > > > > On Wed, Mar 30, 2022 at 10:29 PM CGEL <cgel.zte@gmail.com> wrote: > > > > > > > > > On Wed, Mar 30, 2022 at 10:48:12AM -0400, Paul Moore wrote: > > > > > > > > > > If audit is not generating SYSCALL records, even for invalid/ENOSYS > > > > > > > > > > syscalls, I would consider that a bug which should be fixed. > > > > > > > > > > > > > > > > > > If we fix this bug, do you think audit invalid/ENOSYS syscalls better > > > > > > > > > be forcible or be a rule that can be configure? I think configure is > > > > > > > > > better. > > > > > > > > > > > > > > > > It isn't clear to me exactly what you are asking, but I would expect > > > > > > > > the existing audit syscall filtering mechanism to work regardless if > > > > > > > > the syscall is valid or not. > > > > > > > > > > > > > > Thanks, I try to make it more clear. We found that auditctl would only > > > > > > > set rule with syscall number (>=0 && <2047) ... > > > > > > > > > > That is exactly why I wrote the warning below in my response ... > > > > > > > > > I think the question is more clear now. > > > > > > > > 1) libaudit.c wants to forbid setting invalid syscall, but inconsistent > > > > Currently way(>=0 && <2047) is inconsistent, syscall with number 2000 and > > > > syscall with number 3000 are both invalid syscall. But 2000 can be set by > > > > auditctl, and 3000 cannot be set by auditctl. > > > > A better way to do this forbidden is to use __NR_syscalls(asm-generic/unistd.h). > > > > > > > > 2) if libaudit.c do the right forbidden, kernel better ignore invalid syscall > > > > See this patch. > > > > > > > > If we want audit invalid syscall as you said before. libaudit.c should not > > > > do the forbidden, auditctl should allow setting syscall rule with 'any' number. > > > > So do you think we should fix libaudit.c? > > > > > > I'm having a bit of trouble understanding what you've said above. > > > > > > The kernel ultimately must protect itself from malice and mistakes, so > > > it must verify all data sent to it. > > > > > > Userspace can help by knowing what that kernel policy is so it can avoid > > > violating that policy or provide useful feedback if it can't. Userspace > > > can be used to make things more efficient, but the kernel is the last > > > step for security. > > > > > > If userspace and the kernel are mismatched or out of sync, then the > > > kernel enforces policy to protect itself. > > > > Much appreciate for your interpretation. Have you get any idea of how > > to solve the mismatched? From your viewpoint, I think it's better for > > kernel to not handle syscall of syscall number<0, because it's invaild > > of all arch, and has no value for attacker to probing for specific > > syscall numbers. > > Going back to the very first quoted line above, if you can generate a > test case that shows that audit is missing an auditable event, that is a > bug that should be fixed. > To reproduce "missing auditing invalid syscall": 1.add audit rule auditctl -a always,exit -F arch=b64 -S all 2.run program with invalid syscalls Code as below. Both syscall can not be audited. #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/types.h> #include <sys/time.h> #include <sys/stat.h> #include <sys/syscall.h> #include <fcntl.h> #include <errno.h> int main(int argc, char * argv[]) { int syscall_num = -1; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); syscall_num = 3000; syscall(syscall_num, 0, NULL); printf("syscall num is %d errno is %d, %s, %d\n",syscall_num, errno, __FILE__, __LINE__); return 1; } > > > > > > > > to the audit syscall filter, which are unfortunately baked into the > > > > > > > > current design/implementation, which may affect this to some extent. > > > > > > > > > > -- > > > > > paul-moore.com > > > > > > - RGB > > - RGB > > -- > Richard Guy Briggs <rgb@redhat.com> > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2022-04-07 13:00 UTC | newest] Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-26 9:46 [PATCH] audit: do a quick exit when syscall number is invalid cgel.zte 2022-03-26 9:46 ` cgel.zte 2022-03-26 20:55 ` kernel test robot 2022-03-26 20:55 ` kernel test robot 2022-03-29 1:48 ` CGEL 2022-03-29 1:48 ` CGEL 2022-03-29 1:48 ` CGEL 2022-03-29 2:19 ` Enzo Matsumiya 2022-03-29 2:19 ` Enzo Matsumiya 2022-03-29 2:19 ` Enzo Matsumiya 2022-03-29 3:06 ` Paul Moore 2022-03-29 3:06 ` Paul Moore 2022-03-29 3:06 ` Paul Moore 2022-03-29 3:22 ` CGEL 2022-03-29 3:22 ` CGEL 2022-03-29 3:22 ` CGEL 2022-03-29 13:11 ` Paul Moore 2022-03-29 13:11 ` Paul Moore 2022-03-29 13:11 ` Paul Moore 2022-03-30 5:59 ` CGEL 2022-03-30 5:59 ` CGEL 2022-03-30 5:59 ` CGEL 2022-03-30 14:48 ` Paul Moore 2022-03-30 14:48 ` Paul Moore 2022-03-30 14:48 ` Paul Moore 2022-03-31 2:29 ` CGEL 2022-03-31 2:29 ` CGEL 2022-03-31 2:29 ` CGEL 2022-03-31 14:16 ` Paul Moore 2022-03-31 14:16 ` Paul Moore 2022-03-31 14:16 ` Paul Moore 2022-04-01 1:57 ` CGEL 2022-04-01 1:57 ` CGEL 2022-04-01 1:57 ` CGEL 2022-04-01 13:39 ` Steve Grubb 2022-04-01 13:39 ` Steve Grubb 2022-04-01 13:39 ` Steve Grubb 2022-04-01 14:16 ` Paul Moore 2022-04-01 14:16 ` Paul Moore 2022-04-01 14:16 ` Paul Moore 2022-04-02 8:06 ` CGEL 2022-04-02 8:06 ` CGEL 2022-04-02 8:06 ` CGEL 2022-04-02 15:07 ` Paul Moore 2022-04-02 15:07 ` Paul Moore 2022-04-02 15:07 ` Paul Moore 2022-04-04 15:58 ` Richard Guy Briggs 2022-04-04 15:58 ` Richard Guy Briggs 2022-04-04 15:58 ` Richard Guy Briggs 2022-04-06 1:19 ` CGEL 2022-04-06 1:19 ` CGEL 2022-04-06 1:19 ` CGEL 2022-04-06 16:49 ` Richard Guy Briggs 2022-04-06 16:49 ` Richard Guy Briggs 2022-04-06 16:49 ` Richard Guy Briggs 2022-04-07 2:36 ` CGEL 2022-04-07 2:36 ` CGEL 2022-04-07 2:36 ` CGEL
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.