Summary: | new sec-policy/selinux-makewhatis package | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Brandt (RETIRED) <alunduil> |
Component: | SELinux | Assignee: | SE Linux Bugs <selinux> |
Status: | VERIFIED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | sec-policy r8 | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
makewhatis.te
makewhatis.fc /etc/cron.daily/tmpwatch makewhatis.audit.log |
Description
Alex Brandt (RETIRED)
2012-11-01 17:34:56 UTC
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 |