Hide Forgot
Created attachment 569742 [details] sealert output for dhcpd startup out of default_t directory. Description of problem: We have locally-written software that writes out a dhcpd.conf file and restarts the dhcpd server by calling '/etc/init.d/dhcpd restart'. We see the attached sealert in audit.log. The Target Objects field is hard to read, but it appears to be related to the PWD of the bash script that calls the dhcpd restart. If the script has its PWD in a directory with the default_t context, we get the sealert. If I arrange to 'cd /' before calling the restart, it works fine. All permissions and security contexts for /etc/dhcpd.conf, /var/lib/dhcpd, /var/lib/dhcpd/dhcpd.leases, are okay. I'm not sure that there are any actual operational problems with dhcpd if started in a default_t directory, but it's a nuisance.
This looks like either a leak or you have redirected the output of dhclient to "/ganymede/ganymede/db/logs/make.log.Tue Mar 13 12:09:03 CDT 2012"
Ah, yes, the bash script's stdout/stderr were redirected there. sealert wasn't good enough to decode the Target Object's PATH for me, or else I would have followed that trail. Is that magic documented someplace? I didn't realize selinux would / could object to a previously opened file handle, either. In any event, it does work without alerting if I do a temporary 'cd /' before calling the init.d dhcpd script.
setroubleshoot in RHEL6 does a better job of deciphering this info. ausearch -m avc -i Should "interpret" the AVC. also.
Ah, so it does. Thank you. I still don't understand why dhclient writing to a redirected stderr/stdout causes a policy issue, and why it does not seem to occur if the CWD is moved to / before stopping/starting /usr/sbin/dhcpd, however.
chcon -t var_log_t -R /ganymede/ganymede/db/logs semanage fcontext -a -t var_log_t "/ganymede/ganymede/db/logs(/.*)?" restorecon -R -v /ganymede/ganymede/db/logs If you need it to write, you could label it dhcpc_var_run_t. semanage fcontext -a -t dhcpc_var_run_t "/ganymede/ganymede/db/logs(/.*)?" restorecon -R -v /ganymede/ganymede/db/logs Not sure about why cd / is fixing the problem for you.
The bash script can and does do a number of things, including updating yp maps, restarting ypserv, scp'ing files, accessing remote and local ldap servers, updating MySQL and PostGreSQL, doing an /etc/init.d/named reload, and so on, in addition to restarting dhcp. So far dhcpd is the only thing complaining under the current policy, but given that I'm doing a lot in these build scripts, I'm not sure if there are any guarantees that any given security context label on the logs directory will always be able to simultaneously satisfy policy for everything I'm doing. I assume I could do 'context laundering' by arranging for all of the output from our scripts to go through a pipeline to a perl script or the cat command, or some such, before being spit out to the log file, but I'm surprised that this would be necessary.
Well all confined domains in RHEL5 are allowed to append to a log files. so labelling the log directory as var_log_t and changing > log to >> log, will solve your problem, I believe.
Right, I'll do that, then. Thanks.