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