Samba server Configuration - ACT 2 - Enabling Samba Access through Firewalld and SELinux
In the last article, "Samba Server Configuration - ACT 1", I demonstrated the known procedure of installing and configuring a Samba server. Here, I reveal what was discovered to allow SELinux to enable samba access.
Deploying services on Linux can be fun at the same time challenging. Nothing is as challenging as enabling services to run securely. As discovered previously, Redhat-based linux systems use SELinux and sometimes Firewalld to protect the system from unauthorized access. Samba happens to not be on the list of authorized access. What a shame.
I was able to list a samba share configured on my CentOS 7 VM server, but when I actually tried to access that share in Windows 10, and on the server itself, a constant, annoying message was received, "ACCESS DENIED". I do NOT like rejections, not at ALL. By default, RedHat-based OS systems use a security infrastructure known as Selinux. One of the concepts I understood about selinux, is that, selinux decides what applications are allowed system access and what does not. If the application or entity is required for the system to run smoothly then selinux will relieve restrictions. If not, it is blocked. This was the case with samba.
Sometimes a security program known as "firewalld" might also be installed which again blocks access to the system from un-trusted applications. It is never a good idea, to leave your system unguarded by turning off these security protocols. Samba can be allowed access while enforcing security.
I learned that selinux denies samba access by using "booleans(YES or NOs)", which really means, "allow access to this service: yes or no?" There are several selinux booleans for samba. In a terminal, running this command listed them.
#sudo getsebool -a | grep samba
The "-P" option makes this change permanent.
If you don't have firewalld installed, then the selinux change is all that is needed. However, if you do, then the "zone" that firewalld is monitoring will need to have the samba service added. Firewalld manages a system by placing it in a "zone". Each zone is bound to an IP address pool, a network interface and a set of allowed services.
By default, when first installed, firewalld puts your system in the "public" zone. This zone limits services allowed. You can get a list of services enabled in the public zone by typing,
#sudo firewall-cmd --zone=public --list-all
or
#sudo firewall-cmd --list-all - This command will list the services allowed in the "default" zone, which is "public".
If your system is on a public network, or allows public access, then keep the zone public. Firewalld allows a very limited set of services. The samba service can be manually added to the zone by simply saying,
#sudo firewall-cmd --permanent --zone=public --add-service=samba
#sudo firewall-cmd --reload
However, if you're working on your private system, in which case, only you have access to it, then you should switch your zone to "home". In this zone, more services are allowed, including but not always, samba. There is a catch however. The "public" zone is bounded to your active network interface, most likely managed by "NetworkManager". NetworkManager makes a note of what zone your interface is part of. Even if you switched to zone "home", NetworkManager will still considered your interface part of the "public" zone. It will seem as if nothing has change. At least, that is what I saw.
To tell NetworkManager to place your interface in the "home" zone, if it does not do it automatically, use this command.
#sudo nmcli con mod (connection name, not device name) connection.zone home
sudo nmcli con show - will give you a list of network connecting names
Now your interface is part of the new zone and you can add the samba service as we did with the "public" zone.
Once everything, and it is a lot, is configured correctly, we should be able to access our shares from windows even if the samba server gets rebooted.
Keep in mind, all this is done on a Windows 10 and CentOS 7 machine. What is submitted here is what I have learned and is to help walk an admin or CEO through the configuration of samba.
Stay tuned for ACT - 3 when we permanently mount the share on another Linux OS. May the open source be with you.
Deploying services on Linux can be fun at the same time challenging. Nothing is as challenging as enabling services to run securely. As discovered previously, Redhat-based linux systems use SELinux and sometimes Firewalld to protect the system from unauthorized access. Samba happens to not be on the list of authorized access. What a shame.
I was able to list a samba share configured on my CentOS 7 VM server, but when I actually tried to access that share in Windows 10, and on the server itself, a constant, annoying message was received, "ACCESS DENIED". I do NOT like rejections, not at ALL. By default, RedHat-based OS systems use a security infrastructure known as Selinux. One of the concepts I understood about selinux, is that, selinux decides what applications are allowed system access and what does not. If the application or entity is required for the system to run smoothly then selinux will relieve restrictions. If not, it is blocked. This was the case with samba.
Sometimes a security program known as "firewalld" might also be installed which again blocks access to the system from un-trusted applications. It is never a good idea, to leave your system unguarded by turning off these security protocols. Samba can be allowed access while enforcing security.
I learned that selinux denies samba access by using "booleans(YES or NOs)", which really means, "allow access to this service: yes or no?" There are several selinux booleans for samba. In a terminal, running this command listed them.
#sudo getsebool -a | grep samba
I had no idea which boolean to turn on. I try them all. One of them has to work. Luckily only one boolean needs to be switched on "samba_export_all_rw". My guess, this meant "allow a general samba share with rw access". As you can tell from the above photo, this boolean is switched off by default. To switch it on, and have it stay on permanently, use this command.
#sudo setsebool -P samba_export_all_rw on
The "-P" option makes this change permanent.
If you don't have firewalld installed, then the selinux change is all that is needed. However, if you do, then the "zone" that firewalld is monitoring will need to have the samba service added. Firewalld manages a system by placing it in a "zone". Each zone is bound to an IP address pool, a network interface and a set of allowed services.
By default, when first installed, firewalld puts your system in the "public" zone. This zone limits services allowed. You can get a list of services enabled in the public zone by typing,
#sudo firewall-cmd --zone=public --list-all
or
#sudo firewall-cmd --list-all - This command will list the services allowed in the "default" zone, which is "public".
If your system is on a public network, or allows public access, then keep the zone public. Firewalld allows a very limited set of services. The samba service can be manually added to the zone by simply saying,
#sudo firewall-cmd --permanent --zone=public --add-service=samba
#sudo firewall-cmd --reload
However, if you're working on your private system, in which case, only you have access to it, then you should switch your zone to "home". In this zone, more services are allowed, including but not always, samba. There is a catch however. The "public" zone is bounded to your active network interface, most likely managed by "NetworkManager". NetworkManager makes a note of what zone your interface is part of. Even if you switched to zone "home", NetworkManager will still considered your interface part of the "public" zone. It will seem as if nothing has change. At least, that is what I saw.
To tell NetworkManager to place your interface in the "home" zone, if it does not do it automatically, use this command.
#sudo nmcli con mod (connection name, not device name) connection.zone home
sudo nmcli con show - will give you a list of network connecting names
Now your interface is part of the new zone and you can add the samba service as we did with the "public" zone.
Once everything, and it is a lot, is configured correctly, we should be able to access our shares from windows even if the samba server gets rebooted.
Keep in mind, all this is done on a Windows 10 and CentOS 7 machine. What is submitted here is what I have learned and is to help walk an admin or CEO through the configuration of samba.
Stay tuned for ACT - 3 when we permanently mount the share on another Linux OS. May the open source be with you.
Comments
Post a Comment