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=-1.0 required=3.0 tests=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 2F0F4C2D0F8 for ; Wed, 13 May 2020 00:22:42 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 99F96206F5 for ; Wed, 13 May 2020 00:22:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="inVTIzf/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99F96206F5 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=1589329360; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=0s9KriF3PdXYTKVsT8LkPsSVCIPZmfDY3byV4pHC/GU=; b=inVTIzf/77cZgwYXsa2v00tpO0/2oHP05Po3sOlEVbyGrvhyLCQJc0uHggYOrz8wtROpDg WrdRRSbP1CDYDK5q0m7s6bcOh7iVw1Gy7qQyNJhX59mlIPfcgv9ZgrEneKRiTJnWm1UtRX 8QKNKYtiyR91/KCCFbhjlltTqG5/Tks= 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-219-F2a68BEjOpmWI2LocnS0gw-1; Tue, 12 May 2020 20:22:38 -0400 X-MC-Unique: F2a68BEjOpmWI2LocnS0gw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0EC821899528; Wed, 13 May 2020 00:22:35 +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 5C10F7D908; Wed, 13 May 2020 00:22:32 +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 AD2E14E982; Wed, 13 May 2020 00:22:29 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 04D0MSN3001776 for ; Tue, 12 May 2020 20:22:28 -0400 Received: by smtp.corp.redhat.com (Postfix) id 7483A38E; Wed, 13 May 2020 00:22:28 +0000 (UTC) Received: from x2.localnet (ovpn-112-77.phx2.redhat.com [10.3.112.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4813E1A924 for ; Wed, 13 May 2020 00:22:25 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com Subject: reactive audit proposal Date: Tue, 12 May 2020 20:22:24 -0400 Message-ID: <6360160.ZmnOHIC0Qm@x2> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I wanted to run this by the crowd to see what people's reaction might be. The audit system sometimes needs to have rules applied when something happens. For example, if someone plugs in a USB flash drive, the system creates the device in /dev and then automatically mounts it under some circumstances. I would propose 2 new additions to the audit rule syntax: on-mount and on-login.These rules would be in a separate file from the main audit rules. When a file system is mounted, /proc/mounts changes and the mount table can be scanned to see if something new is there. In this way we can reliably detect newly mounted filesystems. We can then match against a specifier to see if this is a file system in which we want to apply new rules. If so, we send the new rules to the kernel. When the device is unmounted, the kernel drops all watches on that file system. So, we only need to worry about when a device is mounted. This works good for anything that gets mounted. But it is also possible for a USB flash drive to be accessed as a block device, such as the dd utility. If we had to detect device discovery, there is a netlink group, NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing is that we could only detect open/read/write/close/ioctl/lseek. And we probably do not want to monitor anything except block devices. It may also be possible to poll /sys/block to watch for changes. This might be easier as the names are more friendly. This would take some research to see if its even possible. The rule syntax could look something like: on=mount mount=/run/user/1000 : -a exit,always ... on=device device=/dev/sdd : -a exit,always ... The on-login event would simply watch the audit trail for any AUDIT_LOGIN events. That event can be parsed to get the new auid. If the auid matches any rules, then it will load them into the kernel. To remove the rules, we could watch for the AUDIT_USER_END event. The only issue is that we would need to track how many sessions the user has open and remove the rules only when the last session closes out. The rules for this might look something like this: on=login auid=1000 : -a exit,always ... The question is whether or not this should be done as part of the audit daemon or as a plugin for the audit daemon. One advantage of doing this as a plugin is that it will keep the audit daemon focused on getting events and distributing them. Any programming mistake in the plugin will crash it and not the daemon. The tradeoff is that it will get the event slightly after auditd sees it. This only matters for the on-login functionality. The device and mount events come from an entirely different source. And I'm sure that in every case, the program will react faster than a user possibily can winning the race evry time. Thoughts? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit