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 X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60ECFC433DB for ; Tue, 19 Jan 2021 19:15:38 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 09770216FD for ; Tue, 19 Jan 2021 19:15:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09770216FD Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611083735; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=Rs5IQMqX52EDV0K3ntHiSvxaYjeKtMTAB1JZJsO6MjA=; b=VMOx0zcvPpH+3M7gJvNTToV6uwjOG5t+/WZErebMdp+GDlGVLt1ERO6qOJTRt28t7YHhDk saCa2JtZsEFYhovVCzjcH1mQGpEgkBcFi5IxyOuYROmVzYFpEEeRzHhYfBC36pW4+TKGY3 dAZk5a3gE6kzUKivmwmnq6YKF0CnDZU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-170-7676yshvNv-qD7jBQ0TZuQ-1; Tue, 19 Jan 2021 14:15:33 -0500 X-MC-Unique: 7676yshvNv-qD7jBQ0TZuQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 38074107ACE3; Tue, 19 Jan 2021 19:15:30 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D1FB410429F3; Tue, 19 Jan 2021 19:15:29 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 300B04BB7B; Tue, 19 Jan 2021 19:15:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 10JJFAuc019168 for ; Tue, 19 Jan 2021 14:15:10 -0500 Received: by smtp.corp.redhat.com (Postfix) id 606271B058; Tue, 19 Jan 2021 19:15:10 +0000 (UTC) Received: from x2.localnet (ovpn-116-90.rdu2.redhat.com [10.10.116.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 06DA8177F8; Tue, 19 Jan 2021 19:15:06 +0000 (UTC) From: Steve Grubb To: Linux-Audit Mailing List , Joe Wulf Subject: Re: AuditRule Questions Date: Tue, 19 Jan 2021 14:15:06 -0500 Message-ID: <3523142.MHq7AAxBmi@x2> Organization: Red Hat In-Reply-To: <2025971311.1108480.1611079916924@mail.yahoo.com> References: <61239576.993577.1611062133080.ref@mail.yahoo.com> <2759467.e9J7NaK4W3@x2> <2025971311.1108480.1611079916924@mail.yahoo.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: linux-audit@redhat.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 Tuesday, January 19, 2021 1:11:56 PM EST Joe Wulf wrote: > Steve, > > On Tuesday, January 19, 2021, 11:57:03 AM EST, Steve Grubb wrote: > > On Tuesday, January 19, 2021 8:15:33 AM EST Joe Wulf wrote: > > > 1. In audit rules 2.8.5 (front portion of the rules):> > > > ## > > > Unsuccessful file access (any other opens) This has to go last.> > -a > > > always,exit -F arch=b32 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EACCES-a> > always,exit -F arch=b64 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EACCES-a> > always,exit -F arch=b32 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EPERM-a> > always,exit -F arch=b64 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EPERM> > Whereas in audit rules 3.0, the same portion of the > > > same rules looks like:> > -a always,exit -F arch=b32 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EACCES-a> > always,exit -F arch=b32 -S> > > > > open,creat,truncate,ftruncate,openat,open_by_handle_at -F > > > exit=-EPERM-a> > always,exit -F arch=b64 -S> > > > > open,truncate,ftruncate,creat,openat,open_by_handle_at -F > > > exit=-EACCES-a> > always,exit -F arch=b64 -S> > > > > open,truncate,ftruncate,creat,openat,open_by_handle_at -F > > > exit=-EPERM> > > > The ordering of the syscalls differs between the > > > two, as well as the> > sequential order of the rules themselves. I > > > better understand that the> > first audit-rule matched 'wins'.- > > > Please help me understand the reason> > for the change in sequence, > > > but also for the change in the order of the> > syscalls (i.e. between > > > 2.8.5 and 3.0).> > There were several 3.0 alpha releases. I'm not sure > > > which one you are calling > 3.0. Because I can't find an exact match. > > > Based on the text above, I do not > see the syscall ordering changed > > > at all. The only thing that I see is in > 2.8.5 they are grouped by > > > exit code whereas 3.0 is grouped by arch. Since > this group of rules > > > all have the same key, they are working as a team. That > means that > > > what matters is the placement of this group of rules relative to > > > > other groups of rules is what matters. In both cases a syscall can > > > ever only > match one of them - the exit code either is or isn't > > > EPERM, it either is or > isn't b32.>> > > > > > -Steve > > Steve, > Thank you for the wealth of feedback. All very useful. Thank you. > I pulled v3.0 of the audit rules out of RHEL 8.3. > In the sections I referenced, for v2.8.5 the syscalls for b64 are in the > order of:open,create,truncate,ftruncate ..... in v3.0, they are in the > order of:open,truncate,ftruncate,create .... Since, as you say above, the > audit rule can only ever match one syscal.... I'm now understanding the > actual order of the syscall's is no longer relevant on such lines (from an > auditing perspective)? In the kernel, the syscalls in each rule go into a large bitmask so that all can be checked quickly. Ordering within a rule doesn't matter for syscalls. Otherwise, fields are checked sequentially from left to right. So, things that may be false most of the time should be located more to the left for better performance. > In general for a any given system being run and > audited by either set of rules, the end result I suspect would be the > same.The challenge could come in when certain vulnerability tools assess > the system, and do so by seeking an exact match of rule syntax. That is a challenge. That is what drove splitting up the ospp rules into individual files. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit