Hello everyone!! I found this GitHub issue (https://github.com/containers/podman/issues/4490). There were two recommended actions 1. |Add `--security-opt label=disable` while starting the container| 2. |Add `--group-add tty` while starting the container| |The first one worked for me while running Envoyproxy 1.15.0. I would like to understand the security implications of this flag.| |--| |Chintan Mishra| On 08/09/20 10:18 am, Chintan from Rebhu wrote:

On 2020-09-08 10:37, Chintan from Rebhu wrote: That flag disables SELinux confinement for the container. SELinux is one of the more important security features for the container in my opinion - it stopped a number of the more serious container escape vulnerabilities in the past, and provides a lot of safety in ensuring that the container cannot access things it was not meant to even if it breaks out. Can you re-enable SELinux, run the Podman command again, and look for any AVC messages in syslog? It looks like this (changing ownership of the TTY) is probably safe, and we may be able to add it to the default SELinux policy for containers as an allowed action. Providing the AVCs would help us do that. Thanks, Matt Heon

On 9/8/20 09:02, Chris Evich wrote: The SELinux implications of the change are potentially problematic, and I would love to see the AVCs to understnad what is going on. Bottom line with SELinux is we are attempting to prevent the container from modifying anything on the host, in this case it looks like the container is attempting to modify tty's security permissions/ownershift with host based labels that are being handed to the container. If podman was handing the same ttys that are used by the terminal then the container could cause the terminal to potentially do some bad things.  If Podman is creating the tty's handed into the container, then it should be setting the SELinux labels on these ttys to be fully manageable by the container.  I am not sure which is truly the case. I would question an executable needing to modify terminal settings...

What command are you using to launch the Envoyproxy container? The AVC's indicate the container is attempting to write to a fifo_file created by podman # podman run --privileged -v /usr/bin/find:/usr/bin/find fedora find / -type p The issue is I am not getting any information about what fifo file is being blocked? Is this running rootful or rootless? On 9/8/20 13:06, Chintan from Rebhu wrote:

I've had success using udica to craft the selinux policy that can then be applied to the container using the --security-opt flag. See this blog post: https://fedoramagazine.org/use-udica-to-build-selinux-policy-for-containers/ The only place I've noticed udica falling short is running a pod of multiple containers that are all communicating with each other. In this instance I had to start the pod and monitor audit.log for avc denials and then manually update the udica generated .cil file.

Hi Chintan, I got the envoy container running, but used the example config on envoy's Getting Started page: https://www.envoyproxy.io/docs/envoy/latest/start/start Steps I followed: 1) Created a starter container 2) Created an selinux policy using udica 3) Started the container and monitored /var/log/audit/audit.log for denials 4) Updated the udica generated *.cil file everytime the container failed to start, until it finally started. This took 3 attempts, starting on the 4th. Granted, not the most user friendly way of getting the container running, but I think contained from a security standpoint. 1) Starter Container ``` podman create --name envoy \ --label envoy=envoy \ -p 10000:10000 \ -v ${PWD}/envoy_example.yaml:/etc/envoy/envoy.yaml \ envoyproxy/envoy:v1.15.0 ``` 2) Create Policy & remove starter container ``` podman inspect envoy > envoy_container.json udica -j envoy_container.json envoy semodule -i envoy.cil /usr/share/udica/templates/{base_container.cil,net_container.cil} podman rm envoy ``` 3) Create Final Container, attempt to start and monitor audit.log ``` podman create --name envoy \ --security-opt label=type:envoy.process \ --label envoy=envoy \ -p 10000:10000 \ -v ${PWD}/envoy_example.yaml:/etc/envoy/envoy.yaml:Z \ envoyproxy/envoy:v1.15.0 podman start envoy ``` Each time the container failed to start it would log a denial. After each denial I updated the *.cil policy file to allow the denial, and re-applied the policy with: `semodule -i envoy.cil /usr/share/udica/templates/{base_container.cil,net_container.cil}` - Startup 1 ``` type=AVC msg=audit(1599771689.994:11166): avc: denied { read } for \ pid=1194200 comm="docker-entrypoi" path="/lib/x86_64-linux-gnu/libc-2.27.so" \ dev="dm-9" ino=71349652 scontext=system_u:system_r:envoy.process:s0:c76,c889 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0 ``` - Results in allow rule ``` (allow process default_t ( file ( read ))) ``` - Startup 2 ``` type=AVC msg=audit(1599772073.397:11205): avc: denied { setattr } for \ pid=1218170 comm="chown" name="" dev="pipefs" \ ino=6650489 scontext=system_u:system_r:envoy.process:s0:c76,c889 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=fifo_file permissive=0 ``` - Results in allow rule ``` (allow process container_runtime_t ( fifo_file ( setattr ))) ``` - Startup 3 ``` type=AVC msg=audit(1599772272.855:11237): avc: denied { name_bind } for \ pid=1232662 comm="envoy" src=9901 \ scontext=system_u:system_r:envoy.process:s0:c76,c889 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0 ``` - Results in allow rule ``` (allow process unreserved_port_t ( tcp_socket ( name_bind ))) ``` The final *.cil file looked like this: ``` (block envoy (blockinherit container) (blockinherit restricted_net_container) (allow process process ( capability ( audit_write chown dac_override fowner fsetid kill mknod net_bind_service net_raw setfcap setgid setpcap setuid sys_chroot ))) (allow process usr_t ( dir ( open read getattr lock search ioctl add_name remove_name write ))) (allow process usr_t ( file ( getattr read write append ioctl lock map open create ))) (allow process usr_t ( sock_file ( getattr read write append open ))) (allow process default_t ( file ( read ))) (allow process container_runtime_t ( fifo_file ( setattr ))) (allow process unreserved_port_t ( tcp_socket ( name_bind ))) ) ``` Container started and a curl test was successful ``` # podman ps -a --filter "label=envoy=envoy" CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 44f02a9f2ac3 docker.io/envoyproxy/envoy:v1.15.0 envoy -c /etc/env... About a minute ago Up About a minute ago 0.0.0.0:10000->10000/tcp envoy # curl -I localhost:10000 HTTP/1.1 200 OK content-type: text/html; charset=ISO-8859-1 p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info." date: Thu, 10 Sep 2020 21:40:16 GMT server: envoy x-xss-protection: 0 x-frame-options: SAMEORIGIN expires: Thu, 10 Sep 2020 21:40:16 GMT cache-control: private set-cookie: 1P_JAR=2020-09-10-21; expires=Sat, 10-Oct-2020 21:40:16 GMT; path=/; domain=.google.com; Secure set-cookie: NID=204=Py9ONzAvLYe41BNU_HWe88th45fOsxWWmjbh6aodR2wroK8r7gY8blxHV54zG7deSKNmtOT66FQQnyPn8vpk_vb6CwE6ZH-_D3KQgNByttyF2qdUifuYnfzMlirQKv1aWejLrQPdTpt7WDjULDZDTlNpa9BIsvfA4dSShDrfgx4; expires=Fri, 12-Mar-2021 21:40:16 GMT; path=/; domain=.google.com; HttpOnly alt-svc: h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43" x-envoy-upstream-service-time: 64 transfer-encoding: chunked ``` Hope this helps.

On 9/9/20 08:24, Chintan from Rebhu wrote: Could you attache the envoy.yaml?