From nobody Sat Aug 03 20:34:20 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 4WbvZL1Wfzz5T1d7 for ; Sat, 03 Aug 2024 20:34:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WbvZK4tFjz42HY for ; Sat, 3 Aug 2024 20:34:33 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4f51551695cso3368503e0c.3 for ; Sat, 03 Aug 2024 13:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722717272; x=1723322072; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AnkBGPLDoTNDYhqwPJpFV7OdxrHsrMWlGj92DjCtt3I=; b=L1ixsjwcdSHU406lUrkUqooMTcJ0u0UD1rV5ZWKhPUojxLpfZons0PvwbpigLaEMeE n8oBgjdW1r+A2o61C0kl/GEVsTtTiYPT5NcExvLOnTEg3byPkdiyY+wq28aSItb0PqO1 LSgVIEz4oAzC6LXTUwZx2e+Nta/cm0+k+hll1IvWmBc7ZjLt+8fPJuzrdicj4tBJ+AtX OVgTrkMAlsSkVSg08D4X7HWylPil19mlFpDzPwetLqjpYx4HCVqbpkqKAal7MISHi31G B7G/5V3RzWaYYFR9IikzLnmcJUoCYTP8WWisxCvpiAMaWOZS0MPBCS9EsVe+Ktvkvisl ckpQ== X-Gm-Message-State: AOJu0Yz1qT+Uyw9TfmFuRLyjWccdtwGwLmewx7MYHw1Q+vf07UIgPeS0 v06DPKj65xGAkW6LgKhDCMFsnxj4hPq8UtBI2gsauV3xLlsEkchdpuVGV8KmmT4CotxNomI9Yv2 B+JP7hITdR6jP1HntyS6BiM3BGEX+oQ== X-Google-Smtp-Source: AGHT+IGX9kbcLKCexw/SlTZd8OLI/RLadTp7MDCf6tzawW2HL1ugpsKzKfw1HWpdhFCR4hYHj76SS/uLFPcb9JIbM4A= X-Received: by 2002:a05:6122:c91:b0:4f2:a973:8ae with SMTP id 71dfb90a1353d-4f89ff6c5f2mr8709998e0c.5.1722717272075; Sat, 03 Aug 2024 13:34:32 -0700 (PDT) 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 References: <98abd3b2-5d57-439b-aafb-9a497a08e712@quip.cz> In-Reply-To: <98abd3b2-5d57-439b-aafb-9a497a08e712@quip.cz> From: Alan Somers Date: Sat, 3 Aug 2024 14:34:20 -0600 Message-ID: Subject: Re: auditd not logging file operations thru NFS To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WbvZK4tFjz42HY On Sat, Aug 3, 2024 at 1:37=E2=80=AFPM Miroslav Lachman <000.fbsd@quip.cz> = wrote: > > On 03/08/2024 17:06, Alan Somers wrote: > > On Sat, Aug 3, 2024 at 7:52=E2=80=AFAM 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 th= e > >> localhost (on machine A), everything works and the record appears in t= he > >> logfile. However, if a directory is exported via NFS, mounted on anoth= er > >> 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 Yep yep yep. It's definitely surprising. Too bad it isn't easier to fix.