Page 1 of 1

Incorrect SELinux Context (Fedora)

Posted: 16 Jul 2017, 20:33
by mikey_189763
Hello all,

I tried Fedora for the first time today, and CSF failed to install correctly (I've been successful with Centos for quite some time).

Basically the systemd unit files, and the binaries get placed with incorrect SELinux context. I fixed the contexts in /usr/lib/systemd/system/ before I could copy them, but in /usr/sbin they were erroneously:

"unconfined_u:object_r:user_home_t:s0"

The incorrect contexts in the systemd directory caused the CSF and LFD services to not be recognized. The incorrect contexts in /usr/sbin caused the services to fail to start.

Once I fixed the contexts with chcon in both the systemd unit and bin directories, the CSF and LFD services began to start and function normally.

Uname --all = Linux myhostname 4.11.9-300.fc26.x86_64 #1 SMP Wed Jul 5 16:21:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
And my operating system is: Fedora release 26 (Twenty Six)

One thing to point out is that I did not run install.sh as root. I simply used sudo while in the home directory of regular user. Although I feel this shouldn't matter, and it's worked before under Centos.

Re: Incorrect SELinux Context (Fedora)

Posted: 22 Jul 2017, 15:47
by ForumAdmin
Thank you for reporting this. The SELinux security context will be resolved in the next release of csf.

Re: Incorrect SELinux Context (Fedora)

Posted: 09 Aug 2017, 04:14
by mikey_189763
My pleasure. Thank you for making a great product !

Re: Incorrect SELinux Context (Fedora)

Posted: 09 Aug 2017, 04:57
by mikey_189763
So I came back to respond while installing CSF on another new Fedora install. It appears the SELinux context in /usr/lib/systemd/system is correct, but the username still defaulted to my personal username, instead of root, for both lfd.service and csf.service

Now inside the /usr/sbin directory, the contexts appear to be correct "system_u:object_r:bin_t:s0", but the user also defaults to my personal username instead of root.

Fixing username ownership to root:root seemed to fix it this time.