# grep control /etc/unbound/unbound.conf | grep -v '#'
remote-control:
	control-enable: yes
	control-interface: "/run/unbound/unbound.control.pipe"
	control-key-file: "/etc/unbound/unbound_control.key"
	control-cert-file: "/etc/unbound/unbound_control.pem"
# service unbound restart
Redirecting to /bin/systemctl restart unbound.service
# ls -lZ /run/unbound/
total 4
srw-rw----. 1 unbound unbound system_u:object_r:named_var_run_t:s0 0 Dec  9 14:52 unbound.control.pipe
-rw-r--r--. 1 unbound unbound system_u:object_r:named_var_run_t:s0 6 Dec  9 14:52 unbound.pid
# unbound-control status
version: 1.7.3
verbosity: 1
threads: 4
modules: 3 [ ipsecmod validator iterator ]
uptime: 28 seconds
options: reuseport control(namedpipe)
unbound (pid 73069) is running...
#

Following SELinux denials appeared:
----
type=PROCTITLE msg=audit(12/09/2020 14:52:42.751:1374) : proctitle=/usr/sbin/unbound -d 
type=PATH msg=audit(12/09/2020 14:52:42.751:1374) : item=0 name=/run/unbound/unbound.control.pipe inode=756072 dev=00:17 mode=socket,755 ouid=unbound ogid=unbound rdev=00:00 obj=system_u:object_r:named_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/09/2020 14:52:42.751:1374) : cwd=/etc/unbound 
type=SYSCALL msg=audit(12/09/2020 14:52:42.751:1374) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x56461aff3dc0 a1=0660 a2=0x3cf a3=0x0 items=1 ppid=1 pid=73069 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unbound exe=/usr/sbin/unbound subj=system_u:system_r:named_t:s0 key=(null) 
type=AVC msg=audit(12/09/2020 14:52:42.751:1374) : avc:  denied  { fsetid } for  pid=73069 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
type=AVC msg=audit(12/09/2020 14:52:42.751:1374) : avc:  denied  { fsetid } for  pid=73069 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
----

The automated TC (from above-mentioned PR) executed in OSCI environment revealed 1 additional SELinux denial:
----
type=PROCTITLE msg=audit(12/11/2020 04:34:30.280:1043) : proctitle=/usr/sbin/unbound -d 
type=PATH msg=audit(12/11/2020 04:34:30.280:1043) : item=0 name=/run/unbound/unbound.control.pipe inode=72069 dev=00:18 mode=socket,755 ouid=unbound ogid=unbound rdev=00:00 obj=system_u:object_r:named_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/11/2020 04:34:30.280:1043) : cwd=/etc/unbound 
type=SYSCALL msg=audit(12/11/2020 04:34:30.280:1043) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x55c3d2ca00a0 a1=0660 a2=0x3e2 a3=0x0 items=1 ppid=1 pid=30404 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unbound exe=/usr/sbin/unbound subj=system_u:system_r:named_t:s0 key=(null) 
type=AVC msg=audit(12/11/2020 04:34:30.280:1043) : avc:  denied  { fsetid } for  pid=30404 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
type=AVC msg=audit(12/11/2020 04:34:30.280:1043) : avc:  denied  { fsetid } for  pid=30404 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
----
type=PROCTITLE msg=audit(12/11/2020 04:34:30.781:1045) : proctitle=unbound-control set_option cache-max-negative-ttl: 5 
type=PATH msg=audit(12/11/2020 04:34:30.781:1045) : item=0 name=/run/unbound/unbound.control.pipe inode=72069 dev=00:18 mode=socket,660 ouid=unbound ogid=unbound rdev=00:00 obj=system_u:object_r:named_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/11/2020 04:34:30.781:1045) : cwd=/etc/unbound 
type=SOCKADDR msg=audit(12/11/2020 04:34:30.781:1045) : saddr={ saddr_fam=local path=/run/unbound/unbound.control.pipe } 
type=SYSCALL msg=audit(12/11/2020 04:34:30.781:1045) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x3 a1=0x7fff710b18b0 a2=0x6e a3=0x55b6b5846260 items=1 ppid=30471 pid=30478 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unbound-control exe=/usr/sbin/unbound-control subj=system_u:system_r:named_t:s0 key=(null) 
type=AVC msg=audit(12/11/2020 04:34:30.781:1045) : avc:  denied  { connectto } for  pid=30478 comm=unbound-control path=/run/unbound/unbound.control.pipe scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=unix_stream_socket permissive=0 
----

Permissive mode did not reveal any new SELinux denials.

Hi,

unbound needs to change the access rights of the /run/unbound/unbound.control.pipe file using chmod.

>type=PROCTITLE msg=audit(12/11/2020 04:34:30.280:1043) : proctitle=/usr/sbin/unbound -d 
>type=PATH msg=audit(12/11/2020 04:34:30.280:1043) : item=0 name=/run/unbound/unbound.control.pipe inode=72069 dev=00:18 mode=socket,755 ouid=unbound ogid=unbound rdev=00:00 obj=system_u:object_r:named_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
>type=CWD msg=audit(12/11/2020 04:34:30.280:1043) : cwd=/etc/unbound 
>type=SYSCALL msg=audit(12/11/2020 04:34:30.280:1043) : arch=x86_64 syscall=chmod success=yes exit=0 a0=0x55c3d2ca00a0 a1=0660 a2=0x3e2 a3=0x0 items=1 ppid=1 pid=30404 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unbound exe=/usr/sbin/unbound subj=system_u:system_r:named_t:s0 key=(null) 
>type=AVC msg=audit(12/11/2020 04:34:30.280:1043) : avc:  denied  { fsetid } for  pid=30404 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
>type=AVC msg=audit(12/11/2020 04:34:30.280:1043) : avc:  denied  { fsetid } for  pid=30404 comm=unbound capability=fsetid  scontext=system_u:system_r:named_t:s0 tcontext=system_u:system_r:named_t:s0 tclass=capability permissive=0 
 
Do you know for what reason it needs to change the permissions? I ask because, cuz need to know if can be affected somehow functionality of service, when we will don't auditing this permission in SELinux.

Thanks,
Patrik

It seems to me chmod and chown are done just as safeguard to remote socket.

The only use of chmod is in daemon/remote.c [1], where it tries to ensure it has correct rights. It seems current defaults for created unix socket are the same it wants to change it to, user, group and mode are equal to what it wants to se to. I think fstat might be used to check permissions before attempt to change them, the current code seems much simpler.

But I have realized unbound and bind share common context definitions. Unlike unbound, bind has configurable unix socket remote control too. But unlike unbound, administrator has to specify user, group and permissions. Example configuration for named is at [2]. Therefore I think it must be able to change permissions of unix socket anyway. But that basic feature seems working, when changing to groups bind

Is the problem here it changes the socket owner and permissions still as root, before dropping privileges and switching to unbound non-privileged user? It changes chown just in case username: "unbound" in /etc/unbound/unbound.conf is specified. Which is the default of course. Because root is not member of unbound groups, it would be failing, because root special privileges are not granted, right? create_local_accept_sock is called before setresuid. I think that means creating it still as root and changing it to to target user permissions before becoming that user. It would help if it were created later, but now it can be created outside chroot directory.

I think it can be fixed by starting as unbound user from systemd, as proposed in bug #1640285, but that might have other side effects. Not sure it is more safe either.

1. https://github.com/NLnetLabs/unbound/blob/3f7e164751b0f52435ac4d0368ccf8252b3b747b/daemon/remote.c#L310
2. https://bind9.readthedocs.io/en/v9_16_18/reference.html#controls-statement-grammar

I am struggling to fully reproduce this denial. Of course it emits fsetid denial. Can I emulate this denial from gdb or strace tools? When I try it from them, everything works fine, because selinux grants fsetid to root. It first creates the socket owned by root, then changes ownership to unbound user and changes permissions. It seems it works even after denial. Which leads me to suspicion it does not happen where I am checking it. But unless I can use strace, how can I find where exactly this denial happens? Is there good way to debug it in similar way to real use under systemd, when it happens only during startup?

I cannot use attach to systemd started daemon, because it happens too early. Is there something like "sudo" for selinux contexts?

Created attachment 1799786 [details]
patch avoiding fsetid selinux denial

Found a way to avoid it. fsetid is denied because it first changes ownership of the socket to unbound:unbound. Effective UID at that time is still 0, which makes chmod changing file of different user. Strange enough, it still succeeds, it just emits fsetid.

If chmod is done first on root owned file and just then it changes ownership, no such error occurs. Not sure how much this change make sense to upstream. Root usually do not care what is order of these changes.

Hi Petr,

thank you for response and for clarification this issue. So definitely permission with unix stream socket connection will be add to policy, but what will be with fsetid? Do you plan push this patch, which avoiding fsetid denial, to upstream or you already push it? Then we don't need add powerfull fsetid rule to policy.

Thanks,
Patrik

PR:https://github.com/fedora-selinux/selinux-policy/pull/878

To backport:
commit ef940a3a4a811ccb0353d08478c487274d86f3ba (HEAD -> rawhide, upstream/rawhide)
Author: Patrik Koncity <pkoncity>
Date:   Wed Jul 21 16:37:22 2021 +0200

    Allow unbound connectto unix_stream_socket

Namely note it allows only the connect(2) syscall.

Hi Petr,

Do you plan push this patch, which avoiding fsetid denial, to RHEL-8.6 policy?

Thanks,
Patrik

Sorry for delay, I guess fsetid should be fixed on unbound side. Lets check what upstream says.

Is there still any work to do on this bug from your side waiting? Can it be moved to unbound for fsetid fix or should we clone a new bug for unbound change?

Upstream merged fsetid change, can be backported to RHEL.

(In reply to Petr Menšík from comment #25)
> Is there still any work to do on this bug from your side waiting? Can it be
> moved to unbound for fsetid fix or should we clone a new bug for unbound
> change?
> 
> Upstream merged fsetid change, can be backported to RHEL.

There is also the selinux connectto permission problem, so I'll clone this bz to unbound.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1995