Fixes #8989 - Add docker_port_t port and boolean

[lzap]

Boolean passenger_can_connect_docker allows connections to newly created
docker_port_t which is not yet defined in RHEL7/Fedora. This can be used when
users starts Docker on TCP (defaults to UNIX sockets). IANA assigned 2375 and
2376 ports for http/https communication on 2015-01-09.

Denial:

type=AVC msg=audit(1421352630.245:15331): avc: denied { name_connect } for
pid=4803 comm="ruby" dest=2375 scontext=unconfined_u:system_r:passenger_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

@domcleal - in the patch I propose to have that boolean set to true by
default to help non-SELinux aware users.

[lzap]

Added UNIX local sockets for RHEL7+ as well.

[lzap]

@domcleal mind review & merge?

[domcleal]

also update foreman-selinux-disable

[lzap]

Updated, good catch.

[lzap]

Hmmm this will conflict out once #44 is merged due to the elasticport...

[domcleal]

Docker, and below

[lzap]

Copy&paste error, fixed.

[domcleal]

On IRC you're suggesting there's a problem with docker_port_t, could you please explain what it is?

[lzap]

Sure, I've used our internal list simply because Dan and Mirek are subscribed there. Here it is:

Foreman is supported both on RHEL6 and RHEL7. We ship our own policy
in foreman-selinux package.

For version 1.8 there are three services that Foreman application
(passenger_t) needs to connect to. These are:

• ElasticSearch
• Docker
• OpenStack (Nova and others)

In RHEL7 this is not a problem as all the ports are already defined,
except for the ElasticSearch which is not yet in Fedora.

For RHEL6 there is a problem because non of these SELinux ports are
defined yet. My initial idea which already made its way upstream is to
simply define those ports and assign port numbers to them:

• elasticsearch_port_t
• docker_port_t
• osapi_compute_port_t

When I was working on moving some rules from foreman-selinux into
katello-selinux separate package for the Katello plugin, I hit an issue.
When a port type and number are defined, it is not possible to redefine
them. And we will likely hit this problem in future.

I can think of the following situation:

• Foreman user runs an instance with our policy and all the
  ports listed above define. Everything is okay.
• Red Hat SELinux team releases an errata for Core policy that adds
  docker_port_t. Since this was already defined, the yum transaction
  will likely fail. There is no way to upgrade SELinux now on a
  Foreman instance.
• This will be quite hard to fix as port must be undefined, our policy
  must be fixed first removing the port type and new core policy must
  be upgraded then.

I've been discussing this with Mirek from SELinux team already and it
looks like this one is tough. There might be way out by providing a
custom port (foreman_connect_port_t) that would be used to assign all
the ports into until the SELinux core policy is updated. Mirek says that
this could be easier to upgrade, still not ideal tho.

For the record, I've asked on the SELinux Fedora list as well:

https://lists.fedoraproject.org/pipermail/selinux/2015-February/016591.html

[domcleal]

Is this simply because of a possible name conflict? IIRC if the port numbers are also defined that the policies will conflict (e.g. you can't add a new port type that redefines something that's already called something else).

So even if we created a custom port type we could still conflict just on the numbers unless we always removed it immediately before the distro is updated (as if that's possible!).

[lzap]

It's actually both: port type declaration and port number assignement. You cannot redefine single one.

My idea is to create our own type (ideally in some naming convention like custom_whatever_NNNN_port_type) so SELinux can unassign them in the upgrade scriplet. Type declaration is not a problem, they wont be declaring those again. Once core policy is upgraded, we only need to push out update for the new port type (e.g. proper docker_port_t). But the key thing is here we don't get any conflicts during upgrades.

[domcleal]

so SELinux can unassign them in the upgrade scriplet

Do you mean selinux-policy itself?

[lzap]

Yup, that's what we've talked about on DevConf, let's see on the mailing list.

[lzap]

It appears that core policy does not use semanage to define ports, they hardcode it in the policy itself. I don't want to block this, so my proposal is to merge this as is (let's define our ports) and work with them on better solution long-term.

[domcleal]

Thanks @lzap! Merged as 0d132f6.