SELinux and SMB shares unavailable after upgrade to 3.8.15

After my bouts with SELinux and SMB shares… see [SOLVED] Smb permission issues

I’ve run into another issue: After upgrading to Rockstor 3.8.15 I’ve lost access to my SMB shares again.

I was only able to access my home directory share, all the other shares were denied. So I figured it was SELlinux getting in the way again. Sure enough after running

#setenforce 0

and verifying that SELinux was in permissive mode I ran

#tail -f /var/log/audit/audit.log
type=AVC msg=audit(1481132503.452:1921): avc:  denied  { write } for  pid=28711 comm="mnt-share" name="scripts" dev="sde4" ino=45695 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1481132503.452:1921): avc:  denied  { add_name } for  pid=28711 comm="mnt-share" name="mount_share.pyc" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1481132503.452:1921): avc:  denied  { create } for  pid=28711 comm="mnt-share" name="mount_share.pyc" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file permissive=1
type=AVC msg=audit(1481132503.452:1921): avc:  denied  { write } for  pid=28711 comm="mnt-share" path="/opt/rockstor/src/rockstor/scripts/mount_share.pyc" dev="sde4" ino=698989 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1481132503.452:1921): arch=c000003e syscall=2 success=yes exit=4 a0=265cd40 a1=2c1 a2=81a4 a3=7ffeda1fcdd0 items=0 ppid=28687 pid=28711 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mnt-share" exe="/usr/bin/python2.7" subj=system_u:system_r:smbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1481132503.452:1921): proctitle=2F7573722F62696E2F707974686F6E002F6F70742F726F636B73746F722F62696E2F6D6E742D73686172650069736F
type=AVC msg=audit(1481132503.962:1922): avc:  denied  { append } for  pid=28711 comm="mnt-share" name="rockstor.log" dev="sde4" ino=60371 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1481132503.962:1922): arch=c000003e syscall=2 success=yes exit=13 a0=3104680 a1=441 a2=1b6 a3=24 items=0 ppid=28687 pid=28711 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mnt-share" exe="/usr/bin/python2.7" subj=system_u:system_r:smbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1481132503.962:1922): proctitle=2F7573722F62696E2F707974686F6E002F6F70742F726F636B73746F722F62696E2F6D6E742D73686172650069736F
type=AVC msg=audit(1481132504.038:1923): avc:  denied  { execute } for  pid=28713 comm="sh" name="ldconfig" dev="sde4" ino=434447 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1481132504.038:1923): avc:  denied  { read open } for  pid=28713 comm="sh" path="/usr/sbin/ldconfig" dev="sde4" ino=434447 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1481132504.038:1923): avc:  denied  { execute_no_trans } for  pid=28713 comm="sh" path="/usr/sbin/ldconfig" dev="sde4" ino=434447 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1481132504.038:1923): arch=c000003e syscall=59 success=yes exit=0 a0=768550 a1=768620 a2=7674c0 a3=7fff811efd80 items=0 ppid=28712 pid=28713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldconfig" exe="/usr/sbin/ldconfig" subj=system_u:system_r:smbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1481132504.038:1923): proctitle=2F7362696E2F6C64636F6E666967002D70
type=AVC msg=audit(1481132504.096:1924): avc:  denied  { write } for  pid=28717 comm="mnt-share" name="rockon-ztaskd" dev="tmpfs" ino=24083 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=1
type=SYSCALL msg=audit(1481132504.096:1924): arch=c000003e syscall=42 success=yes exit=0 a0=6 a1=34947b0 a2=6e a3=762f2f2f3a637069 items=0 ppid=28687 pid=28717 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mnt-share" exe="/usr/bin/python2.7" subj=system_u:system_r:smbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1481132504.096:1924): proctitle=2F7573722F62696E2F707974686F6E002F6F70742F726F636B73746F722F62696E2F6D6E742D73686172650069736F
type=AVC msg=audit(1481132504.237:1925): avc:  denied  { write } for  pid=28711 comm="mnt-share" name=".s.PGSQL.5432" dev="tmpfs" ino=26148 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:postgresql_var_run_t:s0 tclass=sock_file permissive=1
type=AVC msg=audit(1481132504.237:1925): avc:  denied  { connectto } for  pid=28711 comm="mnt-share" path="/run/postgresql/.s.PGSQL.5432" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:postgresql_t:s0 tclass=unix_stream_socket permissive=1
type=SYSCALL msg=audit(1481132504.237:1925): arch=c000003e syscall=42 success=yes exit=0 a0=3 a1=334aa70 a2=6e a3=334aa72 items=0 ppid=28687 pid=28711 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mnt-share" exe="/usr/bin/python2.7" subj=system_u:system_r:smbd_t:s0 key=(null)
type=PROCTITLE msg=audit(1481132504.237:1925): proctitle=2F7573722F62696E2F707974686F6E002F6F70742F726F636B73746F722F62696E2F6D6E742D73686172650069736F

Now I can access my samba shares over the network but I’m clearly running into SELInux deny problems. Honestly I haven’t had a chance to trouble shoot it past those log issue, I just thought I’d post and see if someone else ran into this, or am I the only one?

1 Like

Further reading up on the issues on other forms with CentOS 7 and SMB share

[root@chipnas ~]# audit2allow -a


#============= postfix_local_t ==============
allow postfix_local_t admin_home_t:file getattr;

#============= smbd_t ==============

#!!!! This avc can be allowed using one of the these booleans:
#     samba_export_all_ro, samba_export_all_rw
allow smbd_t ldconfig_exec_t:file { read open };
allow smbd_t ldconfig_exec_t:file { execute execute_no_trans };

#!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode'
allow smbd_t postgresql_t:unix_stream_socket connectto;
allow smbd_t postgresql_var_run_t:sock_file write;

#!!!! This avc can be allowed using the boolean 'samba_export_all_rw'
allow smbd_t usr_t:dir { write add_name };

#!!!! This avc can be allowed using the boolean 'samba_export_all_rw'
allow smbd_t usr_t:file { write create append };
allow smbd_t var_run_t:sock_file write;

#============= systemd_sysctl_t ==============
allow systemd_sysctl_t tmp_t:file open;

Might be useful.

2 Likes

Champion. I lost access last week, backed everything up anddecided to give freenas another go, got frustrated with it. Reinstalled Rockstor 30 mins ago, set it up, created a share, boom. Same problem. No SMB shares working.

Read your post, made the change. Fixed.

Thanks!

1 Like

I was pulling my hair out with these Samba issues until I ran into this post. Setting seteforce 0 worked for me to give me access to the shares. What downsides should I expect from this, and why is this not working by default (this is a fresh install)?

@Michael_Stufflebeam Thanks for your report and work around here.
Also welcome to Rockstor to @tristancrockett and @Tylor as new forum members.

I’m a little confused by this currently as my understanding was that Rockstor set the following in /etc/selinux/config

 SELINUX=disabled

And that is what I see here on my systems. From @tristancrockett comment and @Tylor fresh install comment it looks like an upstream update may have overwritten something I thought we enforced (although I can’t quite find where this is done now). I’m assuming here that no manual intervention took place with the selinux settings prior to these problems.

I have just checked for this rouge update here by ‘yum update’ and I still have the same setting, as expected, although there were new selinux policy updates. Also I have just checked the setting on a fresh 3.8.15.iso install and it is also disabled and remains this way after then updating this install to 3.8.15-15 testing channel release.

It would be great to work with selinux enabled and my understanding is that there are intentions to move in that direction, which I’m all in favour of, but that currently selinux is disabled.

@suman @Flyer any ideas on this one?

That would be good to know as I’m currently unable to reproduce this problem here.

Hi @phillxnet,
actually have read this thread more than once and can only confirm Rockstor default (dev env + updated env) is without SELinux, so it should be fine

M.

A few notes here. I’m sorry I haven’t had a chance to respond to this over the weekend. I got caught up remodeling a section of my kitchen! My wife is so much happier now :smiley:

So what I have found is that when I install Rockstor on a VM it disables SELinux… When I install Rockstor on physical hardware it enables SELinux. I don’t know why. (Granted that was for Rockstor 3.8.14 I have not reinstalled Rockstor since 3.8.15, just an inplace upgrade.)

@Tylor @tristancrockett running

#setenforce 0
only sets SELinux is permissive mode, it basically disabled SELinux but logs anything to an audit.log so you can see why SELInux is denying access to what ever it is you’re trying to do. It ALSO only sets it to permissive mode for your current boot cycle. If you reboot the box, you’ll go back to enforcing. So you’ll need to make that change permanently.

:end_note

1 Like

@phillxnet

looking at my box, the only thing I had to change when installing on my physical box (no VMs)
[root@chipnas ~]# vim /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

The only thing I changed for installing was making sure my root partition was btrfs. Some how SELinux was getting set to enable too? weird.

@Michael_Stufflebeam Yes this is weird as the test I did earlier was on both a VM (KVM) and real hw but a non UEFI system. And I used the 3.8.15.iso. In both cases I have same as you in that file only with the:

SELINUX=disabled

So I’m still at a bit of a loss.

Thanks for the additional input on this one, hopefully as we get more info on this we can work out what’s going on.

@phillxnet
More hardware note, I’m running an A8-7600 on a gigabyte a88x FM2+ motherboard with 16GB ram and 7 x 3TB hard drives with the primary drive (Rockstor Root) an 120 GB PNY SSD. I believe the motherboard is UEFI.

1 Like

FYI, I’m running Rockstor on the following;

Intel i5-4570t
Gigabyte H97N-WiFi Mini ITX Board
16gb Crucial DDR3-1600 RAM
Intel Quad Port PT/1000 NIC
120gb Samsung 850 EVO SSD
x4 Seagate 4tb SSHD Drives

And just to confirm, this is fresh install.

1 Like

Don’t mean to be debbie downer here but you ALL should be using SELINUX=Permissive unless you have good reason not to. All that means is that selinux won’t enforce ANY actions but give you logs. If you EVER want to use it, you’re all set but if you’re at disabled, this involves redoing all file entries for selinux at a later time. No big deal for new systems. There is also a guide on the forums I helped put together to use SELINUX. I know people don’t like it but once you set it up and get going you don’t have to worry about it much more. You have little protection otherwise if a deamon runs crazy or something gets compromised.

2 Likes

And confirming this is till happening after the latest upgrade to 3.18.16-0.

After upgrading to 3.8.16 I’ve lost access to SMB completely. It asks for a user name and a password but I get denied.

I spoke too soon. After a few reboots, I don’t know what happened, but I was able to get back into my shares no problem this time. Sorry!

I’ve changed hardware today in my NAS. Was unable to reinstall as I couldn’t get the new Skylake hardware booting off USB. (Other linux installers work fine). Reverted to the original installation. Couldn’t access the web GUI. Ran rm /opt/rockstor/.initrock and /opt/rockstor/bin/initrock. Reset up my network and imported the pools from the drives.

Now I cannot access my shares after re-creating them in Samba. Even after running setenforce 0

This is pretty frustrating as I seem to be hitting nothing but pot holes with Rockstor…

EDIT: I’ve moved back to Freenas (reluctantly) until Rockstor is stable. You guys are making a great product and I cant wait to see a stable, mature BTRFS NAS product available. But until that time, I cant afford to keep running into these issues.

This guide would help with the selinux stuff I hope