WIP: apache: tag nginx httpd_runtime files#903
WIP: apache: tag nginx httpd_runtime files#903aerusso wants to merge 2 commits intoSELinuxProject:mainfrom
Conversation
|
I'm not sure of the best way to handle the nginx transition to allow |
|
apachectl is already marked at httpd_exec_t, so this problem is not specific to nginx. I can make a new domain, like httpd_ctl_t, with associated httpd_ctl_roles. Would that be the preferred way to do this? |
This sounds like the best way forward. |
nginx has runtime files that should be appropriately labeled. Signed-off-by: Antonio Enrico Russo <aerusso@aerusso.net>
nginx needs to be executable by system administrators to be able to run various actions, including the critical test option -t. This provides appropriate execution authority to do so. Signed-off-by: Antonio Enrico Russo <aerusso@aerusso.net>
|
I went forward and created a Indeed, it even wants to open various files (for example, the error log that is, at least on my machine, owned by www-data, and root is not explicitly granted access to it). Therefore, it winds up using dac_override. I suppose we could try to interact with various distributions and upstream to make sure that root is given read access to that file, and then we could remove dac_override from both httpd_t and httpd_ctl_t, but for right now this means that httpd_ctl_t needs quite a bit of permission. |
| apache_read_config(logrotate_t) | ||
| apache_domtrans(logrotate_t) | ||
| apache_ctl_domtrans(logrotate_t) | ||
| apache_ctl_domtrans_from_httpd(logrotate_t) |
There was a problem hiding this comment.
This should be a non-from interface call from the apache module. The from interfaces are intended for users to use without having to modify the policy sources.
| manage_dirs_pattern(httpd_ctl_t, httpd_tmp_t, httpd_tmp_t) | ||
| manage_files_pattern(httpd_ctl_t, httpd_tmp_t, httpd_tmp_t) | ||
| allow httpd_ctl_t httpd_tmp_t:file map; | ||
| manage_sock_files_pattern(httpd_ctl_t, httpd_tmp_t, httpd_tmp_t) | ||
| manage_lnk_files_pattern(httpd_ctl_t, httpd_tmp_t, httpd_tmp_t) | ||
| files_tmp_filetrans(httpd_ctl_t, httpd_tmp_t, { file dir lnk_file sock_file }) | ||
| userdom_user_tmp_filetrans(httpd_ctl_t, httpd_tmp_t, dir) | ||
|
|
||
| manage_dirs_pattern(httpd_ctl_t, httpd_tmpfs_t, httpd_tmpfs_t) | ||
| manage_files_pattern(httpd_ctl_t, httpd_tmpfs_t, httpd_tmpfs_t) | ||
| manage_lnk_files_pattern(httpd_ctl_t, httpd_tmpfs_t, httpd_tmpfs_t) | ||
| manage_fifo_files_pattern(httpd_ctl_t, httpd_tmpfs_t, httpd_tmpfs_t) | ||
| manage_sock_files_pattern(httpd_ctl_t, httpd_tmpfs_t, httpd_tmpfs_t) | ||
| fs_tmpfs_filetrans(httpd_ctl_t, httpd_tmpfs_t, { dir file lnk_file sock_file fifo_file }) | ||
|
|
||
| manage_dirs_pattern(httpd_ctl_t, httpd_var_lib_t, httpd_var_lib_t) | ||
| mmap_manage_files_pattern(httpd_ctl_t, httpd_var_lib_t, httpd_var_lib_t) | ||
| manage_lnk_files_pattern(httpd_ctl_t, httpd_var_lib_t, httpd_var_lib_t) | ||
| files_var_lib_filetrans(httpd_ctl_t, httpd_var_lib_t, { dir file }) | ||
|
|
||
| setattr_dirs_pattern(httpd_ctl_t, httpd_runtime_t, httpd_runtime_t) | ||
| manage_dirs_pattern(httpd_ctl_t, httpd_runtime_t, httpd_runtime_t) | ||
| manage_files_pattern(httpd_ctl_t, httpd_runtime_t, httpd_runtime_t) | ||
| manage_sock_files_pattern(httpd_ctl_t, httpd_runtime_t, httpd_runtime_t) | ||
| files_runtime_filetrans(httpd_ctl_t, httpd_runtime_t, { file sock_file dir }) | ||
|
|
||
| manage_dirs_pattern(httpd_ctl_t, squirrelmail_spool_t, squirrelmail_spool_t) | ||
| manage_files_pattern(httpd_ctl_t, squirrelmail_spool_t, squirrelmail_spool_t) | ||
| manage_lnk_files_pattern(httpd_ctl_t, squirrelmail_spool_t, squirrelmail_spool_t) |
There was a problem hiding this comment.
I think this plus especially the port binding makes me reconsider my position...
Overall, I'm beginning to feel this seems too much like httpd_t to make it worthwhile. I'm not definitely saying no, but I'm leaning that direction.
Another option would be to move nginx into a new domain.
There was a problem hiding this comment.
So I've been thinking about how to handle this change. Would it make sense to create an attribute httpd_domains that would be common to both nginx and apache? If we opted to do that, should I create a new httpd module for the common parts, and an nginx module for the new domain?
There was a problem hiding this comment.
That is a possibility. I'd have to see the full extent of rules that use it.
aerusso
changed the title
|
@aerusso are you still working on this? |
|
I am a bit overwhelmed by the choices involved in either creating a new module without mass duplicating things, or refitting apache without creating regressions for apache (which I don't use). It's on the back-burner. If having this PR open represents overhead for you, I can close it and re-open it when I have something more concrete to talk about. |
|
Not a problem to keep open. |
2 participants
nginx has runtime files that should be appropriately labeled