AlmaLinux / cloud-images

Packer templates and other tools for building AlmaLinux images for various cloud platforms.
MIT License
154 stars 48 forks source link

Incorrect SELinux context type on /etc/sysconfig/network-scripts/ifcfg-eth0 #23

Closed ezamriy closed 3 years ago

ezamriy commented 3 years ago

There is a problem with our AWS AMIs: the /etc/sysconfig/network-scripts/ifcfg-eth0 file has invalid SELinux context type system_u:object_r:unlabeled_t:s0 instead of system_u:object_r:net_conf_t:s0.

This leads to the following error if a user tried to change network settings using the nmcli tool:

NetworkManager[783]: <info> [1624210442.3384] audit: op="connection-update" uuid="5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03" name="eth0" args="ipv4.dns-search,connection.timestamp" pid=9325 uid=0 result="fail" reason="failed to update connection: Could not open file '/etc/sysconfig/network-scripts/ifcfg-eth0' for writing: Permission denied"

Steps to reproduce

Run the following command on an AlmaLinux OS official AMI:

$ nmcli connection modify "eth0" ipv4.dns-search 'example.com'

Manual fix instructions

Run the following command:

$ chcon -t net_conf_t /etc/sysconfig/network-scripts/ifcfg*

References

AlmaLinux bug tracker report: almbz#102.

ezamriy commented 3 years ago

I investigated the problem: even if our build scripts are producing a correct image with properly defined SELinux context it doesn't help. The problem is in Amazon's vmimport which is executed automatically by Amazon when we import an AMI using the Packer's amazon-import post-processor. The vmimport tool launches a VM, performs some provisioning and among other steps it generates a new /etc/sysconfig/network-scripts/ifcfg-eth0 file with invalid context. Unfortunately, I can't find a way to fix it easily because vmimport doesn't have any settings and it is executed automatically.

The problem is even worse because when vmimport launches a VM a new /etc/machine-id file is generated and a resulting AMI has it hardcoded. I will create another issue for that problem.

It seems we should change the way we build our AMIs so that vmimport is not executed for our images. I believe we can find a suitable Packer builder/workflow for that: https://www.packer.io/docs/builders/amazon