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 5A3EDC433EF for ; Fri, 1 Apr 2022 13:39:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346460AbiDANli (ORCPT ); Fri, 1 Apr 2022 09:41:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346450AbiDANle (ORCPT ); Fri, 1 Apr 2022 09:41:34 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B4E53377F8 for ; Fri, 1 Apr 2022 06:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648820383; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=h6NQyMqLB58mw6AkprjfrT2eMsB7dX14dgGFHiYBaig=; b=Te19cyqTItTb52oZEDD3sn2FbFExWtyZDX9jMIg6oN91xyskJ2/Gk+Wk6QBgOnzY1wV8N7 zeaanDsJx+1n+Ef/2oaD7x2dJ3IfrMOvUcsc52zxzd3CNq7Bu+3Fm6quJnBaZT6zmVGcHy jvYp1wp0R7Iht0hB82Ac2IykXvwBSmM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-450-nL7KlP4-Pv-1HD6HzTPi4A-1; Fri, 01 Apr 2022 09:39:40 -0400 X-MC-Unique: nL7KlP4-Pv-1HD6HzTPi4A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0E27B101AA64; Fri, 1 Apr 2022 13:39:40 +0000 (UTC) Received: from x2.localnet (unknown [10.22.11.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6157342CFE9; Fri, 1 Apr 2022 13:39:39 +0000 (UTC) From: Steve Grubb To: Paul Moore , linux-audit@redhat.com, CGEL 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 Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid Date: Fri, 01 Apr 2022 09:39:38 -0400 Message-ID: <2777189.mvXUDI8C0e@x2> Organization: Red Hat In-Reply-To: <62465bf3.1c69fb81.d5424.365e@mx.google.com> References: <20220326094654.2361956-1-yang.yang29@zte.com.cn> <62465bf3.1c69fb81.d5424.365e@mx.google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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.133.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 980FDC433FE for ; Fri, 1 Apr 2022 13:39:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648820389; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=k80ksjr0Xbf/JJurcE7jnCSIEX/SNgfT9NkapAgB1aE=; b=SV6/O3+0EI+ku0ibS8T4BFF2YCI95VOjyrvDRswcbz18JwxiCAMpkDK/6G/cTmEr7N3eS5 INzAbxNwyWmWS/zP/vuMdGMoLl/FUWaVcaWhth1mQs/+4Qgt/DNrc5zfHxsGitjzzXMBMe nXE6GxofAJJtMPFFVc15x+6BHtkaFF8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-592-FaEbbHMuMkiV-mTG7OnURA-1; Fri, 01 Apr 2022 09:39:46 -0400 X-MC-Unique: FaEbbHMuMkiV-mTG7OnURA-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 C796B10115F7; Fri, 1 Apr 2022 13:39:44 +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 B4436492C14; Fri, 1 Apr 2022 13:39:43 +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 6EBFC1947BBF; Fri, 1 Apr 2022 13:39:41 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 235311947BBE for ; Fri, 1 Apr 2022 13:39:40 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 0D97942CFEB; Fri, 1 Apr 2022 13:39:40 +0000 (UTC) Received: from x2.localnet (unknown [10.22.11.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6157342CFE9; Fri, 1 Apr 2022 13:39:39 +0000 (UTC) From: Steve Grubb To: Paul Moore , linux-audit@redhat.com, CGEL Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid Date: Fri, 01 Apr 2022 09:39:38 -0400 Message-ID: <2777189.mvXUDI8C0e@x2> Organization: Red Hat In-Reply-To: <62465bf3.1c69fb81.d5424.365e@mx.google.com> References: <20220326094654.2361956-1-yang.yang29@zte.com.cn> <62465bf3.1c69fb81.d5424.365e@mx.google.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 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 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8696957203027343397==" MIME-Version: 1.0 From: Steve Grubb To: kbuild-all@lists.01.org Subject: Re: [PATCH] audit: do a quick exit when syscall number is invalid Date: Fri, 01 Apr 2022 09:39:38 -0400 Message-ID: <2777189.mvXUDI8C0e@x2> In-Reply-To: <62465bf3.1c69fb81.d5424.365e@mx.google.com> List-Id: --===============8696957203027343397== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 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). 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 =3D 2048 -Steve > 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. > = > -- > Linux-audit mailing list > Linux-audit(a)redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit --===============8696957203027343397==--