Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1597076 - selinux preventing haproxy starting (/var/lib/haproxy/stats deny)
Summary: selinux preventing haproxy starting (/var/lib/haproxy/stats deny)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: haproxy
Version: 28
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ryan O'Hara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-02 02:01 UTC by Ian Donaldson
Modified: 2018-07-23 21:24 UTC (History)
9 users (show)

Fixed In Version: haproxy-1.8.12-2.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-23 21:24:06 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Ian Donaldson 2018-07-02 02:01:42 UTC 
Description of problem:

selinux preventing haproxy from starting in fc28.  Worked fine in fc27.


Version-Release number of selected component (if applicable):

haproxy-1.8.8-1.fc28.x86_64
selinux-policy-3.14.1-32.fc28.noarch

How reproducible:

100%

Steps to Reproduce:
1.  setup /etc/haproxy/haproxy.cfg

     contains:  stats socket /var/lib/haproxy/stats

2. systemctl enable haproxy
3. systemctl start haproxy

Actual results:

haproxy not running

Expected results:

haproxy running


Additional info:

worked fine on fc27; distro-sync'd to fc28 and haproxy no longer starts


from /var/log/messages:


Jun 28 05:29:07 HOST audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=haproxy comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jun 28 06:04:54 HOST audit[3167]: AVC avc:  denied  { dac_override } for  pid=3167 comm="haproxy" capability=1  scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=capability permissive=0
Jun 28 06:04:54 HOST haproxy[3167]: [ALERT] 178/060453 (3167) : Starting frontend GLOBAL: error when trying to preserve previous UNIX socket [/var/lib/haproxy/stats]
Jun 28 06:04:54 HOST systemd[1]: haproxy.service: Main process exited, code=exited, status=1/FAILURE
Jun 28 06:04:54 HOST systemd[1]: haproxy.service: Failed with result 'exit-code'.

# ls -alZ /var/lib/haproxy/stats
srwxr-xr-x. 1 root root system_u:object_r:haproxy_var_lib_t:s0 0 Jun 28 06:07 /var/lib/haproxy/stats

Workaround via audit2allow generated rule:

# cat /etc/rc.d/haproxy1.te 

module haproxy1 1.0;

require {
        type haproxy_t;
        class capability dac_override;
}

#============= haproxy_t ==============
allow haproxy_t self:capability dac_override;
Comment 1 Lukas Vrabec 2018-07-03 11:00:21 UTC 
Hi, 

This looks more like packaging issue than SELinux policy one. Moving to proper component.

For more info see:
https://lukas-vrabec.com/index.php/2018/07/03/why-do-you-see-dac_override-selinux-denials/
Comment 2 Ryan O'Hara 2018-07-09 16:52:38 UTC 
I just recreated this problem on F28. The explanation if the blog post linked in comment #1 seems reasonable. In this case haproxy daemon is not running as root:root but rather haproxy:haproxy. The directory where the UNIX socket is being created (/var/lib/haproxy/) is correctly owned by haproxy:haproxy.

I set SELinux to permissive, ran the test again and noticed that the actual stats socket (/var/lib/haproxy/stats) is owned by root:root. I think that is the problem. The haproxy process is running as haproxy:haproxy yet is attempting to create a UNIX socket owned by root:root. Don't have a good solution at the moment.
Comment 3 Ryan O'Hara 2018-07-09 18:11:31 UTC 
The solution is to change the owner of /var/lib/haproxy/ to root:root instead of haproxy:haproxy. This allowed haproxy to start without error using a stats socket. I'll fix the ownership in the spec file and get an update out soon. Thanks for reporting this.
Comment 4 Ryan O'Hara 2018-07-09 18:17:51 UTC 
(In reply to Ryan O'Hara from comment #3)
> The solution is to change the owner of /var/lib/haproxy/ to root:root
> instead of haproxy:haproxy. This allowed haproxy to start without error
> using a stats socket. I'll fix the ownership in the spec file and get an
> update out soon. Thanks for reporting this.

Note that the /var/lib/haproxy/ is the home directory for the haproxy user, which is created at install time. I am not sure if it is acceptable to change this directory's owner/group to anything other than 'haproxy'. I will need to investigate.
Comment 5 Fedora Update System 2018-07-11 15:47:13 UTC 
haproxy-1.8.12-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-941d094624
Comment 6 Fedora Update System 2018-07-11 15:47:25 UTC 
haproxy-1.8.12-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-941d094624
Comment 7 Fedora Update System 2018-07-11 23:40:00 UTC 
haproxy-1.8.12-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-941d094624
Comment 8 Fedora Update System 2018-07-23 21:24:06 UTC 
haproxy-1.8.12-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.