From nobody Sat Aug 3 19:37:46 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WbtJv1crjz5SwfR for ; Sat, 03 Aug 2024 19:37:51 +0000 (UTC) (envelope-from SRS0=oXap=PC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WbtJt5VLQz4t6h; Sat, 3 Aug 2024 19:37:50 +0000 (UTC) (envelope-from SRS0=oXap=PC=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 16621D788C; Sat, 3 Aug 2024 21:37:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1722713868; bh=LUAVlCjenp7oxtLtSIclZ344gkvYeoJoESKQyjNQC3M=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=JOcbPVruEpYsog0fPiB3ewqYIp2e+MXKSP6bk348kQwAHUDzxuyvP3YW2+svmsquy tIIpJM76GcFZ1rr7oS7afwHL+fepFe5k3SvlyFkxbeeQIkUC1Y7Pqm243tVledOzJ9 cSN0kwgfo3BzsmPT5wI8gnsmzWVAH3LF/M4cNaPo= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3B2D5D788B; Sat, 3 Aug 2024 21:37:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1722713867; bh=LUAVlCjenp7oxtLtSIclZ344gkvYeoJoESKQyjNQC3M=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=4GzAb6+hyTCL3eRrOw5denKs2UbpdAqpi0EtfkfyiwlekoqWrdJGPU3aUm+tKGdvG 1eMFTuCkDcrlsZoUpu09nmuTqX8IaOPZ1D1Lgbhwj8apvHdJUZ/Yz9g6kM6BzLXBgL vEaVsRJOEMAR8L9zm5P1Oavv31uJ/d5O/zntWnRk= Message-ID: <98abd3b2-5d57-439b-aafb-9a497a08e712@quip.cz> Date: Sat, 3 Aug 2024 21:37:46 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: auditd not logging file operations thru NFS To: Alan Somers Cc: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] X-Rspamd-Queue-Id: 4WbtJt5VLQz4t6h On 03/08/2024 17:06, Alan Somers wrote: > On Sat, Aug 3, 2024 at 7:52 AM Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> I have auditd running on two machines with a configuration to monitor >> all changes in files on the filesystem. If I write to the file from the >> localhost (on machine A), everything works and the record appears in the >> logfile. However, if a directory is exported via NFS, mounted on another >> machine (machine B), and I write to the file on the machine B, then no >> record appears in the audit log on machine A. >> Is there a way to configure auditd to log these events too? >> >> /etc/security/audit_user is empty >> /etc/security/audit_event is default >> /etc/security/audit_class is default >> >> # cat /etc/security/audit_control >> # >> # $FreeBSD: releng/10.3/contrib/openbsm/etc/audit_control 293161 >> 2016-01-04 16:32:21Z brueffer $ >> # >> dir:/var/audit >> dist:off >> flags:lo,aa,ad,fw,fm,fc,fd >> minfree:5 >> naflags:lo,aa,ad,fw,fm,fc,fd >> policy:cnt,argv >> filesz:50M >> expire-after:600s >> >> Kind regards >> Miroslav Lachman > > Nope. That's a known limitation of auditd. It works at a higher > level than nfs. If you want to audit operations over NFS, currently > you must run auditd on the NFS client. There was actually a GSoC > project that tried to fix this a few years ago, but it ran into too > many problems and was ultimately unsuccessful. Thank you very much for the explanation. I wouldn't have thought that auditd doesn't support it. From my point of view, it's a pretty fundamental bug. If I'm deploying a system for auditing access and changes, I would expect it to be able to record really all accesses to files, but this way all it takes is "some daemon" (NFS) and changes to files can take place without there being an audit trail. Of course, I don't understand these system issues at all and have no idea how difficult it is to fix this deficiency, but I would be happy if the fix could be sponsored by the FreeBSD Foundation. And I would also like to see it mentioned in the manual and handbook. Nowhere did I find mention that the inability to log events through NFS is a long known problem. In this case, fortunately I have access to both machines - the NFS server and the NFS client, so I can take audit logs from the client as well, but in some other cases I am managing an NFS server for foreign clients where I am not able to set up auditd on the client side. Kind regards Miroslav Lachman