I've been getting the following messages out of cron.daily entries that might need a security policy: 1. logrotate_script: line 1: /usr/bin/fail2ban-client: Permission denied This probably needs the following rule or a logrotate interface (along with the syslog interface I saw mentioned recently): allow logrotate_t fail2ban_client_exec_t:file open; # unlink, write, &c The AVCs that are relevant: type=AVC msg=audit(1351746291.316:2914): avc: denied { open } for pid=1144 comm="sh" path="/usr/bin/fail2ban-client" dev="xvda1" ino=577913 scontext=system_u:system_r:logrotate_t tcontext=system_u:object_r:fail2ban_client_exec_t tclass=file type=AVC msg=audit(1351746291.329:2915): avc: denied { open } for pid=1144 comm="sh" path="/usr/bin/fail2ban-client" dev="xvda1" ino=577913 scontext=system_u:system_r:logrotate_t tcontext=system_u:object_r:fail2ban_client_exec_t tclass=file This looks like it is due to the postrotate item in the logrotate script: selinux alunduil # cat /etc/logrotate.d/fail2ban /var/log/fail2ban.log { daily rotate 7 missingok compress postrotate /usr/bin/fail2ban-client set logtarget /var/log/fail2ban.log 1>/dev/null || true endscript } Perhaps we need to allow a transition from cronjob to fail2ban-client? 2. mkdir: cannot create directory â/tmp/whatis.tmp.dir.1149â: Permission denied Could not create /tmp/whatis.tmp.dir.1149 This appears to need the following rule: files_manage_generic_tmp_dirs(system_cronjob_t) But this allowance feels a little dirty to me. Let me know if you can think of a better way to solve the makewhatis job not running in cron. 3. elog rotation error: failed to unlink /var/log/portage/elog: mail-client:mailx-8.1.2.20050715-r6:20120928-233923.log error: failed to unlink /var/log/portage/elog: app-admin:logsentry-1.1.1:20120928-233940.log error: failed to rmdir /var/log/portage/elog: Permission denied I believe the basic rule would be this: allow system_cronjob_t portage_log_t:dir { write setattr }; # unlink, &c Looks like these are due to tmpwatch: type=AVC msg=audit(1351746323.102:3273): avc: denied { setattr } for pid=1178 comm="tmpwatch" name="distfiles" dev="xvda1" ino=675940 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_ebuild_t tclass=dir type=AVC msg=audit(1351746323.146:3274): avc: denied { write } for pid=1179 comm="tmpwatch" name="elog" dev="xvda1" ino=532710 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir type=AVC msg=audit(1351746323.146:3275): avc: denied { write } for pid=1179 comm="tmpwatch" name="elog" dev="xvda1" ino=532710 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir type=AVC msg=audit(1351746323.149:3276): avc: denied { setattr } for pid=1179 comm="tmpwatch" name="elog" dev="xvda1" ino=532710 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir type=AVC msg=audit(1351746323.149:3277): avc: denied { write } for pid=1179 comm="tmpwatch" name="portage" dev="xvda1" ino=532708 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir type=AVC msg=audit(1351746323.149:3278): avc: denied { setattr } for pid=1179 comm="tmpwatch" name="portage" dev="xvda1" ino=532708 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir I'm inclined to say that tmpwatch should have an indication that you want to manage other files (although, I mainly use it for portage files). Perhaps just an interface to access the portage log files in various places? Reproducible: Always
For (1. logrotate and fail2ban) this is most likely solved by introducing a fail2ban_domtrans_client(logrotate_t). I'm not inclined to add it to the policy (yet) as it is a specific setup for your system, and all you need to do is to create a policy to allow it. For (2. makewhatis) I will be putting up a small policy soon for you to test out. If it works, I'll send it upstream for inclusion. For (3. tmpwatch managing portage log files), the name tmpwatch is indeed poorly chosen, as its main function is to remove files that haven't been touched in a while. In that sense, wouldn't it be better to have tmpwatch run in the logrotate domain? What happens if you mark tmpwatch binary as logrotate_exec_t ?
Created attachment 329120 [details] makewhatis.te
Created attachment 329122 [details] makewhatis.fc Simple makewhatis policy, care to try this one out? Make sure that the makewhatis script is marked makewhatis_exec_t before you do.
1. That's acceptable. I still feel that it should be upstreamed but understand the argument for keeping it local. I have this policy in place locally for now. It appears to be working correctly. 2. I've loaded the makewhatis policy you uploaded and will report back with the results on the next makewhatis update. 3. I've started work on a tmpwatch policy. I'm inclined to believe that adding tmpwatch to the logrotate domain doesn't solve the problem (it accesses *tmp_t files not *log_t files). Would you prefer me to try the logrotate label or continue work on the policy?
Does tmpwatch really only focus on tmp files? Since your AVC denials are leading me to believe it also does log files and such: """ type=AVC msg=audit(1351746323.146:3275): avc: denied { write } for pid=1179 comm="tmpwatch" name="elog" dev="xvda1" ino=532710 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir type=AVC msg=audit(1351746323.149:3276): avc: denied { setattr } for pid=1179 comm="tmpwatch" name="elog" dev="xvda1" ino=532710 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:portage_log_t tclass=dir """ If not for trying to 'clean' the Portage log location (which afaik doesn't contain tmp files) then what is it trying to do in the portage log location?
You are correct. The default configuration only touches tmp_t files but has sections for portage that include distfiles and log files. Of course, an admin can specify any other directories or files to purge after a specified time as well. I'm not sure what the best way to handle a general purpose file deletion utility would be? Maybe just an unlink on all files? What do you suggest Sven? I'm attaching the tmpwatch configuration I use so you can see what I mean.
Created attachment 329244 [details] /etc/cron.daily/tmpwatch The "configuration" (cron) file for tmpwatch that cleans various directories of "expired" files.
I think a good "in-the-middle" approach here would be to support some booleans to allow the tmpreaper domain to purge logfiles and portage_ebuild_t (for the distfiles) and perhaps even any non-auth/security file. But then again, that might be a bit too much (the latter). RedHat also allows tmpreaper to remove user files (unconditionally) so it's not a too weird approach.
BTW, just noticed that tmpreaper wasn't mentioned in the bugreport ;-) It looks like that module is responsible for the tmpwatch stuff. But it currently only supports purging tmp files afaics (except on redhat, where it also purges user files).
I'm still trying to learn my way around the SELinux modules and didn't know about the tmpreaper module. I think at this point we should make tmpwatch depend on selinux-tmpreaper and then start fixing any outstanding issues (as you mentioned, portage items) there. If you think that's reasonable I'll start working with tmpreaper to continue that work and remove the tmpwatch policy I had barely begun.
Only thing I see wrong with the makewhatis policy is a missing: miscfiles_read_localization(makewhatis_t) The AVCs I got during the last run are attached. The errors I received: /usr/sbin/makewhatis: line 452: cd: /root: Not a directory error: cannot open current directory error: cannot open current directory error: cannot open current directory error: cannot open current directory It's not obvious that the last four are due to makewhatis and should be taken as potential issues (but I don't see anything in the AVCs that would indicate they are from makewhatis.
Created attachment 329466 [details] makewhatis.audit.log The aforementioned AVCs for makewhatis.
Are the denials from enforcing mode? If you add in the miscfiles_read_localization() and userdom_search_user_home_dirs() calls, does that resolve both most of the denials /and/ the errors?
That did resolve all of the denials except the following: type=AVC msg=audit(1352959518.551:2616): avc: denied { getsched } for pid=18968 comm="sort" scontext=system_u:system_r:makewhatis_t tcontext=system_u:system_r:makewhatis_t tclass=process And it resolved the error I was expecting it to but not these: error: cannot open current directory error: cannot open current directory error: cannot open current directory error: cannot open current directory As I said I'm not convinced those are coming from makewhatis so I wouldn't worry too much (probably tmpwatch). The only thing I see left on the makewhatis is what to do with the getsched call. My initial thought is dontaudit but I'm not sure what the implications of allowing it to get its own schedule would be (seems benign to me).
Yeah, I'm also inclined to support getsched/setsched if the application does it by default (after all, policies are to prohibit the non-standard accesses - the non-standard behavior). The errors you notice should still be resolved, otherwise we'll get bug reports from other users anyhow. As you don't see a denial yet, does something show when you disable dontaudit (semodule -DB)?
Okay, selinux-makewhatis live ebuild is now available, and policy is committed to repo. Will be in r8.
r8 in hardened-dev overlay
When this finally gets stabilized, we'll want sys-apps/man to pull selinux-makewhatis in when selinux is specified. Also, did we add the dependency to tmpwatch to pull in selinux-tmpreaper?
I didn't add the dependency on tmpreaper yet, will do now.
r8 is now in main tree, ~arch
r8 is now stable
