2:41 p.m.
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?
Thanks in advance.
3:26 p.m.
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
5:57 p.m.
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?
On Wed, Feb 10, 2021 at 6:26 PM Steve Grubb <sgrubb(a)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
4:14 p.m.
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(a)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
7:48 p.m.
First, thanks for the feedback!
AV> I thought that any filesystem operation requested by a user in Windows
would necessarily be executed by some user in Linux in the end (...)
Is that assumption incorrect?
SG> Maybe. It depends on the implementation. If its all in the kernel, then
probably not.
AFAIK the Samba daemon in Linux just 1) listens to Windows file requests,
2) forwards them to the kernel via syscalls and 3) sends the file operations
return codes back to Windows. There is no user-space filesystem
implementation
as in FUSE.
SG> 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.
If I strace the Samba daemon processes, I see the open syscalls called when
I create dummy files in the Windows network drive that is mapped to the
Linux
directory via Samba. I still don't understand why the kernel's audit engine
doesn't
know who to attribute the access to. Doesn't it have access to the files'
owner
Linux user ?
For instance, after creating two dummy files, I have this in the Linux
directory
served by Samba:
$ ls /data -lah
total 8.0K
drwxrwxrwx 2 root root 48 Feb 11 20:08 .
dr-xr-xr-x. 21 root root 4.0K Jan 27 10:32 ..
-rwxrwxr-x+ 1 aevangelista domainusers 0 Feb 11 20:07 alantest1.txt
-rw-r--r-- 1 aevangelista domainusers 0 Feb 11 20:08 alantest2.txt
Shouldn't auditd be able to see that aevangelista is the Linux user ID
related to the open syscall and log it ? Sorry if I'm missing something
obvious.
Thanks again in advance!
12:35 p.m.
Hello,
Moderation system finally works. All messages / membership requests are
approved.
On Thursday, February 11, 2021 8:48:57 PM EST Alan Evangelista wrote:
AV> I thought that any filesystem operation requested by a user in
Windows
> would necessarily be executed by some user in Linux in the end (...)
> Is that assumption incorrect?
SG> Maybe. It depends on the implementation. If its all in the kernel, then
probably not.
AFAIK the Samba daemon in Linux just 1) listens to Windows file requests,
2) forwards them to the kernel via syscalls and 3) sends the file
operations return codes back to Windows. There is no user-space filesystem
implementation
as in FUSE.
SG> 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.
If I strace the Samba daemon processes, I see the open syscalls called when
I create dummy files in the Windows network drive that is mapped to the
Linux directory via Samba. I still don't understand why the kernel's audit
engine doesn't know who to attribute the access to. Doesn't it have access
to the files' owner Linux user ?
Since Samba is accessing the file, it sees Samba's loginuid. It pulls this
from the task struct when the open occurs. The loginuid is set by pam during
authentication. Since the Samba process is started by systemd, it doesn't go
through any kind of authentication and therefore has the default -1 loginuid.
The audit rules are generally written to avoid logging any daemon activity
since that is not as interesting. What users do is more interesting.
For instance, after creating two dummy files, I have this in the
Linux
directory served by Samba:
$ ls /data -lah
total 8.0K
drwxrwxrwx 2 root root 48 Feb 11 20:08 .
dr-xr-xr-x. 21 root root 4.0K Jan 27 10:32 ..
-rwxrwxr-x+ 1 aevangelista domainusers 0 Feb 11 20:07 alantest1.txt
-rw-r--r-- 1 aevangelista domainusers 0 Feb 11 20:08 alantest2.txt
Shouldn't auditd be able to see that aevangelista is the Linux user ID
related to the open syscall and log it ? Sorry if I'm missing something
obvious.
When it logs a PATH record, you will get the ownership and mode information
in that record. However, it is likely not triggering any rule because audit
rules that are shipped generally avoid daemons.
If your rule was:
-a always,exit -F dir=/data -F perm=wra -F key=Samba-access
Then you should get every read or write in the /data dirctory.
Best Regards,
-Steve
1353
days inactive
1359
days old
linux-audit@lists.linux-audit.osci.io
5 comments
2 participants
participants (2)
-
Alan Evangelista -
Steve Grubb