connect.2: can return EACCES because of SELinux

connect.2: can return EACCES because of SELinux

[Stefan Puiu]

Hi Michael,

Hope you are well with the lockdown and all.

Recently I had to troubleshoot a problem where a connect() call was
returning EACCES:

17648 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 37
17648 connect(37, {sa_family=AF_INET, sin_port=htons(8081),
sin_addr=inet_addr("10.12.1.201")}, 16) = -1 EACCES (Permission
denied)

I've traced this to SELinux policy denying the connection. This is on
a Fedora 23 VM:

$ cat /etc/redhat-release
Fedora release 23 (Twenty Three)
$ uname -a
Linux mako-fedora-01 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The manpage says this can happen when connecting to a broadcast
address, or when a local firewall rule blocks the connection. However,
the address above is unicast, and using 'wget' from another account to
access the URL works fine.

The context is that we're building an OS image, and this involves
downloading RPMs through a proxy. The proxy (polipo) is labelled by
SELinux, and I guess there is some sort of policy that says "proxy can
only connect to HTTP ports". When trying to connect to a server
listening on a port that is not labeled as an HTTP server port, I
guess SELinux steps in. With 'setenforce 0', the build works fine. In
the kernel sources I see connect() calls security_socket_connect()
(see https://elixir.bootlin.com/linux/latest/source/net/socket.c#L1855),
which calls whatever security hooks are registered. I see the SELinux
hook getting registered at
https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L7047,
and setting a perf probe on the call proves that the
selinux_socket_connect function gets called (while tcp_v4_connect() is
not).

How about adding this to the manpage?

diff --git a/man2/connect.2 b/man2/connect.2
index 125ca33ef..9763739c7 100644
--- a/man2/connect.2
+++ b/man2/connect.2
@@ -155,6 +155,13 @@ in the path prefix.
 The user tried to connect to a broadcast address without having the socket
 broadcast flag enabled or the connection request failed because of a local
 firewall rule.
+
+.B EACCES
+can also be returned if a SELinux policy denied a connection (for
+example, if there is a policy saying that an HTTP proxy can only
+connect to ports associated with HTTP servers, and the proxy tries to
+connect to a different port).
+
 .TP
 .B EADDRINUSE
 Local address is already in use.
@@ -297,4 +304,5 @@ is shown in
 .BR getsockname (2),
 .BR listen (2),
 .BR socket (2),
-.BR path_resolution (7)
+.BR path_resolution (7),
+.BR selinux (8)

Re: connect.2: can return EACCES because of SELinux

[Michael Kerrisk (man-pages)]

Hello Stefan,,

On 5/29/20 9:11 AM, Stefan Puiu wrote:
> Hi Michael,
> 
> Hope you are well with the lockdown and all.
> 
> Recently I had to troubleshoot a problem where a connect() call was
> returning EACCES:
> 
> 17648 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 37
> 17648 connect(37, {sa_family=AF_INET, sin_port=htons(8081),
> sin_addr=inet_addr("10.12.1.201")}, 16) = -1 EACCES (Permission
> denied)
> 
> I've traced this to SELinux policy denying the connection. This is on
> a Fedora 23 VM:
> 
> $ cat /etc/redhat-release
> Fedora release 23 (Twenty Three)
> $ uname -a
> Linux mako-fedora-01 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> The manpage says this can happen when connecting to a broadcast
> address, or when a local firewall rule blocks the connection. However,
> the address above is unicast, and using 'wget' from another account to
> access the URL works fine.
> 
> The context is that we're building an OS image, and this involves
> downloading RPMs through a proxy. The proxy (polipo) is labelled by
> SELinux, and I guess there is some sort of policy that says "proxy can
> only connect to HTTP ports". When trying to connect to a server
> listening on a port that is not labeled as an HTTP server port, I
> guess SELinux steps in. With 'setenforce 0', the build works fine. In
> the kernel sources I see connect() calls security_socket_connect()
> (see https://elixir.bootlin.com/linux/latest/source/net/socket.c#L1855),
> which calls whatever security hooks are registered. I see the SELinux
> hook getting registered at
> https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L7047,
> and setting a perf probe on the call proves that the
> selinux_socket_connect function gets called (while tcp_v4_connect() is
> not).
> 
> How about adding this to the manpage?

I thought I replied to this message, but it looks like I did not.
As you may already have realized, I applied this patch. Thanks
for sending it.

Cheers,

Michael

> 
> diff --git a/man2/connect.2 b/man2/connect.2
> index 125ca33ef..9763739c7 100644
> --- a/man2/connect.2
> +++ b/man2/connect.2
> @@ -155,6 +155,13 @@ in the path prefix.
>  The user tried to connect to a broadcast address without having the socket
>  broadcast flag enabled or the connection request failed because of a local
>  firewall rule.
> +
> +.B EACCES
> +can also be returned if a SELinux policy denied a connection (for
> +example, if there is a policy saying that an HTTP proxy can only
> +connect to ports associated with HTTP servers, and the proxy tries to
> +connect to a different port).
> +
>  .TP
>  .B EADDRINUSE
>  Local address is already in use.
> @@ -297,4 +304,5 @@ is shown in
>  .BR getsockname (2),
>  .BR listen (2),
>  .BR socket (2),
> -.BR path_resolution (7)
> +.BR path_resolution (7),
> +.BR selinux (8)
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: connect.2: can return EACCES because of SELinux

[Stefan Puiu]

Hi Michael,

On Fri, Jun 12, 2020 at 11:08 PM Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
>
> Hello Stefan,,
[...]
> I thought I replied to this message, but it looks like I did not.
> As you may already have realized, I applied this patch. Thanks
> for sending it.

Yes, I did see my name mentioned in the release notes, together with
the patch title :).

Thanks!

>
> Cheers,
>
> Michael