Security context issues and suggestions
Posted: 10 Dec 2014, 00:43
Greetings! First, I wanted to thank the dev for a great product. I just got it up and running on CentOS 6.6 / RHEL 6 and it's working wonderfully.
I did however have great difficulties setting everything up and I suspect other users may run into similar issues.
I will outline my issues below and after, will suggest how additional documentation would be helpful to avoid and fix the issues.
I followed the CentOS directions carefully with the intent of getting CloneZilla running to image machines in our office. I have DHCP running on a pfSense firewall, which was working fine as far as I could tell and the initial PXE sequence would successfully obtain an IP address, but after about a minute the PXE sequence would timeout stating: PXE-E32: Open Timeout.
Most research online points to some sort of tftp mis-configuration, which was certainly a red herring on the surface. I quadruple-checked absolutely every part of the setup (DHCP, TFTP, NFS, SAMBA, etc) and found everything to be accurate the way I had intended. What made the issue more difficult to troubleshoot is that in.tftp was apparently not logging in /var/log/messages or anywhere I could tell. I tried connecting manually using the TFTP client from another machine and trying to 'get' pxelinux.0, this fortunately, logged into messages, but I kept getting the following error: in.tftpd[1922]: Cannot open map file: /tftpboot/erpxe.remap: Permission denied
I confirmed that the permissions were 777 on /tftpboot, so this was very perplexing. Upon further sleuthing I read a suggestion to run ls -Z /tftpboot to check the SELinux security context. I did so, and the results appeared as below:
I'll be honest, I wasn't quite sure what that was supposed to look like, however I was desperate at that point, so I tried the subsequent suggestion to run: restorecon -r /tftpboot
I did so, and observed the changes below:
My next attempt to PXE boot was successful and tailing messages spewed tons of wonderful and useful information to me. I really hope that this can save some others out there hours of troubleshooting.
Now to my suggestions. I don't honestly know enough about this to determine how I encountered the issue to begin with, but is it possible that the contents of the erpxe-1.2.tar.gz were packaged with incorrect security context? If not, possibly a section in the installation documentation to assist people in dealing with this problem by using the restorecon command
Also using the current packages in CentOS, the tftp daemon is now called tftp not tftpd, so that should be updated in the instructions. Obviously this suggestion is very minor, but worth noting.
Thanks again for your hard work and a great tool!
I did however have great difficulties setting everything up and I suspect other users may run into similar issues.
I will outline my issues below and after, will suggest how additional documentation would be helpful to avoid and fix the issues.
I followed the CentOS directions carefully with the intent of getting CloneZilla running to image machines in our office. I have DHCP running on a pfSense firewall, which was working fine as far as I could tell and the initial PXE sequence would successfully obtain an IP address, but after about a minute the PXE sequence would timeout stating: PXE-E32: Open Timeout.
Most research online points to some sort of tftp mis-configuration, which was certainly a red herring on the surface. I quadruple-checked absolutely every part of the setup (DHCP, TFTP, NFS, SAMBA, etc) and found everything to be accurate the way I had intended. What made the issue more difficult to troubleshoot is that in.tftp was apparently not logging in /var/log/messages or anywhere I could tell. I tried connecting manually using the TFTP client from another machine and trying to 'get' pxelinux.0, this fortunately, logged into messages, but I kept getting the following error: in.tftpd[1922]: Cannot open map file: /tftpboot/erpxe.remap: Permission denied
I confirmed that the permissions were 777 on /tftpboot, so this was very perplexing. Upon further sleuthing I read a suggestion to run ls -Z /tftpboot to check the SELinux security context. I did so, and the results appeared as below:
Code: Select all
drwxrwxr-x. root root unconfined_u:object_r:default_t:s0 bin
drwxrwxr-x. root root unconfined_u:object_r:default_t:s0 boot
-rwxrwxr-x. root root unconfined_u:object_r:default_t:s0 CHANGELOG
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 CREDITS
drwxrwxr-x. root root unconfined_u:object_r:default_t:s0 doc
drwxrwxr-x. root root unconfined_u:object_r:default_t:s0 er
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 erpxe.remap
lrwxrwxrwx. root root unconfined_u:object_r:default_t:s0 er.remap -> erpxe.remap
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 gpxelinux.0
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 gpxelinuxk.0
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 ipxelinux.0
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 LICENSE
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 lpxelinux.0
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 pxelinux.0
drwxrwxr-x. root root unconfined_u:object_r:default_t:s0 pxelinux.cfg
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 README.md
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 RELEASENOTES
-rw-rw-r--. root root unconfined_u:object_r:default_t:s0 undionly.kpxe
I did so, and observed the changes below:
Code: Select all
drwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 bin
drwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 boot
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 CHANGELOG
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 CREDITS
drwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 doc
drwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 er
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 erpxe.remap
lrwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 er.remap -> erpxe.remap
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 gpxelinux.0
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 gpxelinuxk.0
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 ipxelinux.0
lrwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 ldlinux.c32 -> boot/isolinux/ldlinux.c32
lrwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 libcom32.c32 -> boot/isolinux/libcom32.c32
lrwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 libutil.c32 -> boot/isolinux/libutil.c32
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 LICENSE
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 lpxelinux.0
-rw-r--r--. root root unconfined_u:object_r:tftpdir_t:s0 memdisk
drwxr-xr-x. root root unconfined_u:object_r:tftpdir_t:s0 netboot
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 pxelinux.0
drwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 pxelinux.cfg
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 README.md
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 RELEASENOTES
-rwxrwxrwx. root root unconfined_u:object_r:tftpdir_t:s0 undionly.kpxe
Now to my suggestions. I don't honestly know enough about this to determine how I encountered the issue to begin with, but is it possible that the contents of the erpxe-1.2.tar.gz were packaged with incorrect security context? If not, possibly a section in the installation documentation to assist people in dealing with this problem by using the restorecon command
Also using the current packages in CentOS, the tftp daemon is now called tftp not tftpd, so that should be updated in the instructions. Obviously this suggestion is very minor, but worth noting.
Thanks again for your hard work and a great tool!