Attached is a new policy for logsentry that works for me on the 9999 policies. Reproducible: Always
Created attachment 327968 [details] logsentry.te
Created attachment 327970 [details] logsentry.fc
You define a logsentry_tmp_t but there doesn't seem to be a transition towards this type. But then you define the following: """ files_search_tmp(logsentry_t) files_delete_tmp_dir_entry(logsentry_t) files_manage_generic_tmp_dirs(logsentry_t) files_manage_generic_tmp_files(logsentry_t) """ I think this is because the transition doesn't occur, and you need to manage your own tmp files here. Perhaps the following helps as well: """ (assuming a directory is created ) files_tmp_filetrans(logsentry_t, logsentry_tmp_t, dir) """ Change "dir" with "file" if only files are created, or "{ file dir }" if directories & files are created at the same location. Also: """ corecmd_exec_ls(logsentry_t) """ This is deprecated; you can use corecmd_exec_bin(logsentry_t) here instead. What is the following used for? """ corecmd_mmap_sbin_files(logsentry_t) """
I've made the changes you suggest (thank you) and removed the mmap_sbin files directive. Everything appears to be working correctly. I'll upload the new policies once I've verified thoroughly that things are working correctly.
Created attachment 328134 [details] logsentry.fc
Created attachment 328136 [details] logsentry.te
In the policy, you currently have: """ manage_files_pattern(logsentry_t, logsentry_filter_t, logsentry_filter_t) """ However, if for logsentry the filter files are input, why does it need to manage those? Does it really need to write or remove filter files? If not, perhaps they are better left as generic etc_t files (unless we want to define a logsentry_admin later to allow certain roles access to these files). There are also a few duplicate entries in the policy. For instance, logging_search_logs(logsentry_t) already provides files_search_var(logsentry_t). Also, if you provide manage rights, then you don't need to provide read or write privileges. Make sure that the manage rights are indeed needed: """ logging_read_generic_logs(logsentry_t) logging_write_generic_logs(logsentry_t) logging_manage_generic_logs(logsentry_t) """ and """ logging_read_audit_log(logsentry_t) logging_manage_audit_log(logsentry_t) """ The method corecmd_getattr_sbin_files(logsentry_t) is already deprecated, and mentions corecmd_getattr_bin_files as its successor. However, you already provide corecmd_exec_bin - why does it need to get the attributes of the binary files?
I added the logsentry_filter_t as a tracker to see if those files were indeed accessed in any other way. You are correct that they don't appear to be necessary. Your parenthetical about having an admin label to restrict roles' access was one of my thoughts with this as well but only a fleeting one. Does this mean you would still suggest removing that type and letting the etc_t type roll down? Thanks for pointing out the redundant directives. The manage is hit on because of the offset files that logsentry writes to indicate where to seek to next time it reads that particular log file: selinux selinux # ls -lZ /var/log/everything/ -rw-r--r--. 1 root root system_u:object_r:var_log_t 124458 Nov 10 14:30 current -rw-------. 1 root root system_u:object_r:var_log_t 13 Nov 10 14:05 current.offset If you can think of a better way to manage these files (probably a transition to logsentry_tmp_t?); I would love to hear it. Wouldn't this still require manage on var_log_t though (for file creation and modification)? This inclines me towards going with straight manage rights but the transition to another type would help in locking it down to which files the administrator actually wants to watch. The core script is simply a shell script that runs other shell commands (most notably egrep). Because it's a shell script it wants to exec bash as well: type=AVC msg=audit(1352581531.170:4786): avc: denied { read } for pid=27580 comm="logcheck.sh" path="/bin/bash" dev="xvda1" ino=627495 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:shell_exec_t tclass=file Thus, corecmd_exec_shell(logsentry_t). The following AVCs indicate getattr_sbin but I'm not seeing any obvious reason why this would be. type=AVC msg=audit(1352585129.580:4910): avc: denied { getattr } for pid=23387 comm="logcheck.sh" path="/bin/date" dev="xvda1" ino=576614 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.580:4911): avc: denied { getattr } for pid=23385 comm="logcheck.sh" path="/bin/rm" dev="xvda1" ino=576654 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.803:4912): avc: denied { getattr } for pid=23385 comm="logcheck.sh" path="/bin/egrep" dev="xvda1" ino=1010688 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.806:4913): avc: denied { getattr } for pid=23393 comm="logcheck.sh" path="/bin/egrep" dev="xvda1" ino=1010688 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.806:4914): avc: denied { getattr } for pid=23394 comm="logcheck.sh" path="/bin/egrep" dev="xvda1" ino=1010688 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.810:4915): avc: denied { getattr } for pid=23385 comm="logcheck.sh" path="/bin/egrep" dev="xvda1" ino=1010688 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file type=AVC msg=audit(1352585129.810:4916): avc: denied { getattr } for pid=23385 comm="logcheck.sh" path="/bin/rm" dev="xvda1" ino=576654 scontext=system_u:system_r:logsentry_t tcontext=system_u:object_r:bin_t tclass=file After trying this with corecmd_exec_bin instead everything works just fine. I'm attaching the current versions and await any further feedback you can provide. Thanks for everything Sven!
Created attachment 329148 [details] logsentry.fc
Created attachment 329150 [details] logsentry.te
Well, I think it makes sense to keep it with logsentry_filter_t (or perhaps a more generic logsentry_etc_t) as we might want to allow specific roles access to these files, but not to all etc files. And it also makes sense to have it generic etc_t. So I'm in the middle. I'll keep it with the specific context, but can you try having /etc/logcheck(/.*) marked as logsentry_etc_t (btw, why is it logsentry module and all logcheck binaries?)? You can still have /etc/logcheck/tmp(/.*)? marked as logsentry_tmp_t and such, but it will allow the use of a logsentry_admin() interface later.
I'm the same way. I could go either way on the filter_t files marking. If you come up with a compelling reason to go either way let me know but I agree for now keeping it marked special so we can add an admin interface later. I'll make the context changes when I get a few moments later today and report back my status. The logcheck/logsentry confusion is part of upstream's choice on how to package things. I'm not inclined to fix it. (The package is logsentry but all of the files are named logcheck ...)
Changes are working just fine. I'm uploading what I currently have.
Created attachment 329480 [details] logsentry.fc
Created attachment 329482 [details] logsentry.te
Starts looking good. Doesn't the script generate logging somewhere (as I don't notice a logsentry_log_t file type)? It has manage rights on generic log files currently, this might hide the fact that it too logs. Same with lock files or PID files?
Nope, the only files it generates (I'll attach an strace -e open output) are tmp files and offset files (next to read log files).
Created attachment 329584 [details] strace -e open -f /etc/cron.hourly/logsentry.cron
Live ebuild added to the tree, te/fc/if file (with logsentry_admin()) provided as well. Will be part of r8. However, DEPENDS on this package will only be possible the moment the package is stabilized (as it is a new package).
r8 in hardened-dev overlay
r8 is now in main tree, ~arch
r8 is now stable
