Re: Samba and AuditD

Re: Samba and AuditD

[Steve Grubb]

Hello,

Moderator system is acting up. But it'll go through eventually.

On Wednesday, February 10, 2021 3:41:45 PM EST Alan Evangelista wrote:
> I have installed audit 2.8.5 on a CentOS 7 and set up the following rule in
> /etc/audit/rules.d/audit.rules:
> 
> -w /data
> 
> /data is shared via Samba to a Windows Server 2016 system. If I write to
> /data in the CentOS7 system, I get the open syscall event in the auditd
> log. If I write to the same directory in the Windows Server 2016, I see the
> file in the /data directory in the CentOS7 system, but the event is not
> logged by audit. Is that the expected behavior?

Unfortunately, yes. The Linux kernel has no idea who the user is in the 
Windows machine since they're not really logged in. This applies to all 
remote files systems. They may yield a few events, but that is more by 
accident than design.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Samba and AuditD

[Steve Grubb]

Hello,

Moderating System still messed up today...

On Wednesday, February 10, 2021 6:57:28 PM EST Alan Evangelista wrote:
> SG>  The Linux kernel has no idea who the user is in the
> Windows machine since they're not really logged in. This applies to all
> remote files systems.
> 
> I thought that any filesystem operation requested by a user in Windows
> would necessarily be executed by some user in Linux in the end (either a
> generic user such as samba or, in my specific case, the Linux user which is
> mapped to the MS Active Directory user by Centrify). After all, the
> filesystem is managed by Linux. Is that assumption incorrect?

Maybe. It depends on the implementation. If its all in the kernel, then 
probably not. This is the case with several file systems such as NFS. If the 
file system is served from user space then you may get events. I have heard of 
some file system servers opening the device and using it directly.

Basically, if you can strace the daemon and see it accessing the file system 
with the sycalls you expect, then the kernel's audit engine can capture the 
access but won't know who to attribute it to.

-Steve

> On Wed, Feb 10, 2021 at 6:26 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > Hello,
> > 
> > Moderator system is acting up. But it'll go through eventually.
> > 
> > On Wednesday, February 10, 2021 3:41:45 PM EST Alan Evangelista wrote:
> > > I have installed audit 2.8.5 on a CentOS 7 and set up the following
> > > rule
> > 
> > in
> > 
> > > /etc/audit/rules.d/audit.rules:
> > > 
> > > -w /data
> > > 
> > > /data is shared via Samba to a Windows Server 2016 system. If I write
> > > to
> > > /data in the CentOS7 system, I get the open syscall event in the auditd
> > > log. If I write to the same directory in the Windows Server 2016, I see
> > 
> > the
> > 
> > > file in the /data directory in the CentOS7 system, but the event is not
> > > logged by audit. Is that the expected behavior?
> > 
> > Unfortunately, yes. The Linux kernel has no idea who the user is in the
> > Windows machine since they're not really logged in. This applies to all
> > remote files systems. They may yield a few events, but that is more by
> > accident than design.
> > 
> > -Steve




--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit