-
Notifications
You must be signed in to change notification settings - Fork 160
WIP: apache: tag nginx httpd_runtime files #903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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 <[email protected]>
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 <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a possibility. I'd have to see the full extent of rules that use it.
nginx has runtime files that should be appropriately labeled