1

I'm noticing some files within a web directory with changed file contexts that deviates from system policy. There are developers that run git pull against at a higher part of the web directory and I'm wondering if that could be the cause, but my tests have shown git to respect the SELinux labelling rules. To be explicit, this is not changing the labelling rules, just the labels on a specific directory and its decendents. And a restorecon -R is enough to fix it.

Is it possible to track what makes changes to file contexts and when? Is that something auditd is capable of tracking? As it stands, the audit log and /var/log/secure do not show anything that obviously would have made the change. Is there a syscall I could instrument with ftrace or something?

How would one go about tracking down this change?

1 Answers1

0

I ended up using auditd for this. File contexts are stored in the extended attributes of the file on the filesystem itself, thus to change a file context, a setxattr() syscall must be made. So I can audit all of the setxattr calls to files in a specific directory path, and to limit the noise a little more, I can only audit successful calls (because I only care when the context is actually changed). Thus my rule looks like this:

auditctl -a always,exit -F arch=b64 -S setxattr -F dir=/var/dir/path -F success=1 -k fcontext_detect

This produces messages similar to the following:

type=SYSCALL msg=audit(1586191225.091:52361): arch=c000003e syscall=188 success=yes exit=0 a0=12ff173 a1=6f53e8918efa a2=12cd598 a3=1f items=1 ppid=20206 pid=20513 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2179 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="fcontext_detect"

@powerload79 mentioned the possibility of using fanotify. Which may work, but I found the documentation wanting, and the audit rule turned out to be easier and good enough.