Here’s my Caddyfile:
{
# Not necessary, I just don't like the admin API
admin off
http_port 8080
# Required for Quest compatibility. If OCSP stapling is left on, serving files to
# Quest may work for up to one week, but will then fail due to expiration issues.
# The OCSP bug can be confirmed by leaving OCSP stapling on, waiting 8 days, and
# then running `curl -v --cert-status https://HOSTNAME/``, which will end with
# the error `curl: (91) OCSP response has expired`.
ocsp_stapling off
}
localhost:8443 {
file_server browse {
root /www-tir-na-nog/root
}
reverse_proxy /api/* localhost:9000
forward_auth /files/restricted/* localhost:9000 {
uri /verify
}
log {
output file /www-tir-na-nog/access.log
}
}
Note: The hostname has been temporarily set to localhost for testing.
My caddy.service file:
# caddy.service
#
# For using Caddy with a config file.
#
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.
[Unit]
Description=Caddy web server
Documentation=https://caddyserver.com/docs/
After=network.target
[Service]
Type=notify
User=caddy
Group=caddy
#User=den-antares
#Group=den-antares
#ExecStartPre=/usr/bin/caddy validate --config /etc/caddy/Caddyfile
#ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
#ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
ExecStartPre=/usr/bin/caddy validate --config /www-tir-na-nog/Caddyfile
ExecStart=/usr/bin/caddy run --environ --config /www-tir-na-nog/Caddyfile
ExecReload=/usr/bin/caddy reload --config /www-tir-na-nog/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
#PrivateTmp=true
#ProtectHome=true
ProtectHome=false
#ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
When I run caddy from systemd with User=caddy, I get the follow error:
den-antares@patchwork-starfish www-tir-na-nog$ curl https://localhost:8443/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
When I run with User=den-antares, HTTPS does work. I’d prefer to run it under the caddy user if possible.
Audit2allow shows a lot of stuff:
#============= httpd_t ==============
allow httpd_t config_home_t:dir { add_name create write };
allow httpd_t config_home_t:file { create open write };
#!!!! This avc can be allowed using the boolean 'httpd_read_user_content'
allow httpd_t config_home_t:file open;
allow httpd_t data_home_t:dir { add_name create remove_name write };
#!!!! This avc can be allowed using the boolean 'httpd_read_user_content'
allow httpd_t data_home_t:file { getattr open read };
allow httpd_t data_home_t:file { create open unlink write };
allow httpd_t default_t:dir { add_name read };
allow httpd_t default_t:file { append create getattr open read write };
allow httpd_t default_t:lnk_file { getattr read };
allow httpd_t fprintd_t:dbus send_msg;
#!!!! This avc can be allowed using the boolean 'httpd_read_user_content'
allow httpd_t home_cert_t:file { getattr open read };
allow httpd_t home_cert_t:file write;
allow httpd_t pam_var_run_t:dir read;
allow httpd_t pam_var_run_t:file { lock open read write };
#!!!! This avc can be allowed using the boolean 'daemons_dump_core'
allow httpd_t root_t:file getattr;
#!!!! This avc can be allowed using the boolean 'httpd_mod_auth_pam'
allow httpd_t self:capability audit_write;
#!!!! This avc can be allowed using the boolean 'httpd_mod_auth_pam'
allow httpd_t self:netlink_audit_socket nlmsg_relay;
allow httpd_t shadow_t:file { getattr open read };
allow httpd_t sudo_db_t:dir read;
#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow httpd_t unreserved_port_t:udp_socket name_bind;
#!!!! This avc can be allowed using the boolean 'httpd_read_user_content'
allow httpd_t user_home_t:dir read;
allow httpd_t user_home_t:dir add_name;
#!!!! This avc can be allowed using the boolean 'httpd_read_user_content'
allow httpd_t user_home_t:file { open read };
allow httpd_t user_home_t:file { create open write };
#!!!! This avc can be allowed using the boolean 'httpd_enable_homedirs'
allow httpd_t user_home_t:lnk_file read;
#============= iiosensorproxy_t ==============
#!!!! This avc is allowed in the current policy
allow iiosensorproxy_t self:unix_dgram_socket create;
allow iiosensorproxy_t sysfs_t:dir write;
allow iiosensorproxy_t sysfs_t:file write;
allow iiosensorproxy_t syslogd_var_run_t:dir search;
#============= systemd_homed_t ==============
allow systemd_homed_t var_t:dir read;
#============= virtqemud_t ==============
allow virtqemud_t user_home_dir_t:file { relabelfrom relabelto setattr write };
…but in my experience, trying to fix SELinux issues with audit2allow is a fool’s errand. Sure, it’ll work at first, but then your server will crash later at the most inconvenient possible time and there will be a new permission that needs to be added. Then again. And again. And again. Basically if you have to edit SELinux stuff you are guaranteed months of instability and debugging. If it comes down to it, disabling SELinux is generally the better option.
But seriously, if you could show us: