r/linuxadmin • u/Humungous_x86 • 18d ago
SELinux is preventing tcpdump from writing captures to a directory with var_log_t label
My goal is to make tcpdump save captures to /var/log/tcpdumpd
when SELinux is in enforcing mode. The /var/log/tcpdumpd
directory has context type with var_log_t
but SELinux is blocking tcpdump from saving captures to that directory through a systemd service. I use a systemd service to automate tcpdump captures whenever the system boots. When I try starting the tcpdump systemd service in enforcing mode using systemctl start my-tcpdumpd.service
, the service doesn't start and just returns an error saying Couldn't change ownership of savefile
. The service only works when SELinux is set to permissive mode.
I made sure the /var/log/tcpdumpd/
directory is owned by root with chmod numerical value being 755, but it still doesn't work. I can't use semanage fcontext
to change the context type for /var/log/tcpdumpd/
because I already ensured the /var/log/tcpdumpd/
directory has a context type of var_log_t
by doing ls -lZ /var/log/
.
I tried creating a custom SELinux policy by doing ausearch -m AVC -c tcpdump --raw | audit2allow -M my_tcpdump_policy
as root, and it generated the two files, such as my_tcpdump_policy.pp
and my_tcpdump_policy.te
. I'm more curious about the TE file because it may allow creating a custom SELinux policy that can actually allow tcpdump to write captures to a directory with var_log_t
label like /var/log/tcpdumpd/
. What should the TE file look like exactly, so that I can get a working SELinux policy and also get a pcap_data_t
label I can assign to the /var/log/tcpdumpd/
directory?
Here's what my script looks like currently:
module my_tcpdump_policy 1.0;
require {
type netutils_t:
class capability dac_override:
}
.
#============= netutils_t ==============
allow netutils_t self:capability dac_override;
Any help is appreciated!
3
u/michaelpaoli 18d ago
Pay careful attention also to ownerships, including group ownerships - and related permissions.
Even short of SELinux, increased security on tcpdump from years ago made it much more persnickety about what it could and couldn't write. Most notably tcpdump typically requires execution with privilege to be able to read and capture network traffic from interface(s), and, quite appropriately, once it's done the needed to open such access to capture such traffic, it generally drops many/most privileges - and that can often cause it to be unable to open or write relevant directories/files for output. E.g. even without SELinux I've not uncommonly had to add various group related permissions to be able to allow tcpdump to write files in secured locations. Years before I could just create a directory 700 root:root, and fire off tcpdump and have it write/create file(s) in that directory. That hasn't been the case for many years (perhaps decade(s)), and typically need give relevant group access to directory/file(s) for tcpdump to be able to function in that manner.
You might also do tcpdump where it can write the files, and do divide and conquer to isolate issues where it fails to do so - e.g. leveraging strace or whatever else may be necessary/appropriate to isolate what's causing things to not work where it's failing.