From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DE5FDC433EF for ; Fri, 1 Apr 2022 12:29:52 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-619-ZT9yCMNyP-OFZA6ukBzVuQ-1; Fri, 01 Apr 2022 08:29:48 -0400 X-MC-Unique: ZT9yCMNyP-OFZA6ukBzVuQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9ED3B1C00B91; Fri, 1 Apr 2022 12:29:47 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 29EBD400F3A; Fri, 1 Apr 2022 12:29:46 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id E62001947BBF; Fri, 1 Apr 2022 12:29:45 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id EEC5519451F3 for ; Fri, 1 Apr 2022 01:57:50 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id B409E40CF8F2; Fri, 1 Apr 2022 01:57:50 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF92340CF8EB for ; Fri, 1 Apr 2022 01:57:50 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 28DBC3C11A34 for ; Fri, 1 Apr 2022 01:57:12 +0000 (UTC) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-340-i5-AVUxRN8i6q2nEZTkxsw-1; Thu, 31 Mar 2022 21:57:10 -0400 X-MC-Unique: i5-AVUxRN8i6q2nEZTkxsw-1 Received: by mail-qk1-f169.google.com with SMTP id w141so1058264qkb.6; Thu, 31 Mar 2022 18:57:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=its5ZVzLNySBxXzZdl/ejpOgC699lFgiSCphdNqxw3M=; b=TowfAqGIl3biJmC/X5BQUz9zX6bwQ0uNd7Vhd7Z7f8pKRQMrNZjdJdyqYoj1jKOElK jpT3C37MRDB7u+XL4jW32sSN0IHc3XMkQ7q0pwNyea9fO/2C/wcS6iy6I72qfFLdx8Wt OfeYQUY0iIbmdxKowEbaPeCdfB6FRPs8wXDUmAjUtuJSx8q5RkjBRySfATZe6yxTqdOW UYXw3XJQ7iLxK09r/UCFJF07U56UpHrvs9H8BT2IOUlnymQdHBFr/SeZ9fkaAQ7eemfh gvw4VMsDX9TXuZNYjBZtIyXYdYPVD4O00qvEj0loVdo+6GIfm4nXaLfP6/XMNzeU/cv+ BpMg== X-Gm-Message-State: AOAM530THYX+38FOnTjrJYDZ0TZCDQkEx3QTwh1jRfAt4VT5rrz7WJb7 WFmzkhn+I/ZPrxH/9eLwrYArghxBtLo= X-Google-Smtp-Source: ABdhPJw5E4iL6lKbhxPnTqk3ytLmMT3d0XS35G1p5m72cwroJPbaVszP2yOmiqWTcX/HWoqtsqrWfw== X-Received: by 2002:a05:620a:17a6:b0:67d:85e6:a86b with SMTP id ay38-20020a05620a17a600b0067d85e6a86bmr5161830qkb.771.1648778229629; Thu, 31 Mar 2022 18:57:09 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id p64-20020a37a643000000b0067d9afad07asm540901qke.76.2022.03.31.18.57.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 18:57:07 -0700 (PDT) Message-ID: <62465bf3.1c69fb81.d5424.365e@mx.google.com> X-Google-Original-Message-ID: <20220401015705.GB2404167@cgel.zte@gmail.com> Date: Fri, 1 Apr 2022 01:57:05 +0000 From: CGEL To: Paul Moore Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid References: <20220326094654.2361956-1-yang.yang29@zte.com.cn> <202203270449.WBYQF9X3-lkp@intel.com> <62426553.1c69fb81.bb808.345c@mx.google.com> <62427b5c.1c69fb81.fc2a7.d1af@mx.google.com> <6243f1d7.1c69fb81.b19c7.7ec1@mx.google.com> <6245121e.1c69fb81.ea0ab.0c2e@mx.google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mailman-Approved-At: Fri, 01 Apr 2022 12:29:44 +0000 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kbuild-all@lists.01.org, Zeal Robot , linux-kernel@vger.kernel.org, eparis@redhat.com, dai.shixin@zte.com.cn, Yang Yang , linux-audit@redhat.com, ink@jurassic.park.msu.ru, huang.junhua@zte.com.cn, guo.xiaofeng@zte.com.cn, mattst88@gmail.com, rth@twiddle.net Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6853672248171443817==" MIME-Version: 1.0 From: CGEL To: kbuild-all@lists.01.org Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid Date: Fri, 01 Apr 2022 01:57:05 +0000 Message-ID: <62465bf3.1c69fb81.d5424.365e@mx.google.com> In-Reply-To: List-Id: --===============6853672248171443817== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL 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 (>=3D0 && <2047). So if userspace using syscall whose number is (<0 || >=3D2047), 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 (>=3D0 && <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 =3D trace_get_syscall_nr(current, regs); if (syscall_nr < 0 || syscall_nr >=3D 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 --===============6853672248171443817==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F9ECC433EF for ; Fri, 1 Apr 2022 01:57:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243909AbiDAB7D (ORCPT ); Thu, 31 Mar 2022 21:59:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233627AbiDAB7B (ORCPT ); Thu, 31 Mar 2022 21:59:01 -0400 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F58525846E for ; Thu, 31 Mar 2022 18:57:10 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id d65so1062523qke.5 for ; Thu, 31 Mar 2022 18:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=its5ZVzLNySBxXzZdl/ejpOgC699lFgiSCphdNqxw3M=; b=C+GinWkGW9kXz8S6iY+9Pa9rt93JXP8qXPcM7cyM/jl5JN0MK/MszALO65g7eVVcNo moXRGmHiuJcQWFwiOgIjWa+tDd9pU344v6THdrDj/wl4eFD4I051N/1xdLob+ilsA6rb gVbS1yJI9UAm/3LHAIclPG45LI6qw3xBwRwr9D5wMgLREvzX6Ie2NSZ4ivgpOMe0QgXl BB1gsGEOaO1InqfxQAEmO/kUsu6LhCc9NxFvJs0e6u+HyJA12v6rJdIsGZqPUJ/MuzAp tJxvdzG7jnekAAIQAhQ2ICFITGWS70nHoVdgbjbmPy0iRvi6xm9cylIgnzdWXk5nqLLU /Vhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=its5ZVzLNySBxXzZdl/ejpOgC699lFgiSCphdNqxw3M=; b=B/hTDzk4osJu72t9x6hc2YCWRonEopDfaOhco1rcpsHw+QEHrNsyPjqt7ykWtntaCf Ipw49ARdA5Wrr2wVNz0f4T/4R7D31cgU5FXMbN5FiSi1c0CV3hPT2T5z0XP8w9tXN4SB XmtMtHDScCyAoCJt6Esh4VFrUbR5W9oJnCTsSysZ8WWLk6mFLFYyx65cQK5gdJTQXhPu xh/8U3Ld/1T2QMtLszBovNzBzPREazQGupUhXFYeW45uv/vkbRi6m8mIl6MydPfws1+5 kwCfb2t4Om42u6rNe1NRrvY2Jk5XpTu+TfoWL5iA2/NmR45J3R+wvP3jDo4QQQS9FtSx WVQg== X-Gm-Message-State: AOAM533aQXZo7ROnIoiTplx9Cqq4wyJF3QZGyJ+UX2eG0/7Q9PJu1U5K G+CigKbAI10xynRrTKI671Q= X-Google-Smtp-Source: ABdhPJw5E4iL6lKbhxPnTqk3ytLmMT3d0XS35G1p5m72cwroJPbaVszP2yOmiqWTcX/HWoqtsqrWfw== X-Received: by 2002:a05:620a:17a6:b0:67d:85e6:a86b with SMTP id ay38-20020a05620a17a600b0067d85e6a86bmr5161830qkb.771.1648778229629; Thu, 31 Mar 2022 18:57:09 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id p64-20020a37a643000000b0067d9afad07asm540901qke.76.2022.03.31.18.57.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 18:57:07 -0700 (PDT) Message-ID: <62465bf3.1c69fb81.d5424.365e@mx.google.com> X-Google-Original-Message-ID: <20220401015705.GB2404167@cgel.zte@gmail.com> Date: Fri, 1 Apr 2022 01:57:05 +0000 From: CGEL To: Paul Moore Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, eparis@redhat.com, linux-audit@redhat.com, kbuild-all@lists.01.org, linux-kernel@vger.kernel.org, Yang Yang , Zeal Robot , guo.xiaofeng@zte.com.cn, huang.junhua@zte.com.cn, dai.shixin@zte.com.cn Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid References: <20220326094654.2361956-1-yang.yang29@zte.com.cn> <202203270449.WBYQF9X3-lkp@intel.com> <62426553.1c69fb81.bb808.345c@mx.google.com> <62427b5c.1c69fb81.fc2a7.d1af@mx.google.com> <6243f1d7.1c69fb81.b19c7.7ec1@mx.google.com> <6245121e.1c69fb81.ea0ab.0c2e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 31, 2022 at 10:16:23AM -0400, Paul Moore wrote: > On Wed, Mar 30, 2022 at 10:29 PM CGEL 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