Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

Tag Archives: SELinux

RHEL 7 mock build with staff_selinux

By default, mock won’t work with staff_selinux mode in RHEL 7. The instruction from Fedora is mostly correct, but insufficient for staff_selinux. This is because:

  1. /usr/bin/mock is now a sym-link to /usr/bin/consolehelper, thus consolehelper permission should be also allowed.
  2. The Fedora mock policy module does not have the types like staff_consolehelper_t.

There are a lot more reasons, but long story short, I have edited a policy file (PackageMaintainers_MockTricks_mock.te) that should covered the most mock usage. My SELinux skill quickly build up by editing that file. 🙂

Time for script that setup the mock, assuming you are running as root:

# getting dependencies
yum -y install selinux-policy-devel policycoreutils-python mock

# Download policy files

# Build and install
make -f /usr/share/selinux/devel/Makefile
semodule -i PackageMaintainers_MockTricks_mock.pp

That’s it.

But just in case you are still getting SELinux AVC denials, you can get around yourself by using following scripts:

grep -E -e "(mock|consolehelper)" /var/log/audit/audit.log | audit2allow -M my_mock
semodule -i my_mock.pp

SELinux for synergy , or generally other tcp/udp services

If you enforcing your SELinux and set your user to non unconfined_u, like either user_u or staff_u. You may found that your synergy or other tcp/udp service stop working. That is because your role cannot listen the ports that your services required.

To allow users to run TCP servers (bind to ports and accept connection from the same domain and outside users), run:

sudo setsebool selinuxuser_tcp_server 1

and for UDP:

sudo setsebool selinuxuser_udp_server 1


  1. user SELinux Policy documentation (8)

SSH Troubleshoot: Having valid key but still fall back to password

Do you have a valid key and the public key is ~/.ssh/authoried_keys of target ssh server, but you still need to type password? Here is the checklist you can refer:

  1. ~/.ssh  and its content should not have read/write permission for other users
    cd ; chmod og-rw .ssh
  2. Same goes with your remote directory ~/.ssh
  3. Your server home directory should not have read/write permission for other users
    cd ~/..; chmod o-rw <homeDir>
  4. If SELinux is enforced in server, make sure the SELinux type of ~/.ssh in server is user_ssh_home_tcd;  ls -dZ .ssh   # to list the SELinux type of ~/.ssh
    chcon -R -t user_ssh_home_t .ssh
  5. ssh -vvv <login@server> to get more information on the local side.
  6. See server log /var/log/secure for sshd output. Change LogLevel to DEBUG3  in /etc/ssh/sshd_config and restart sshd to get more detail debugging messages.
  7. See server log /var/log/audit/audit.log for SELinux log.

Note that this checking is for Fedora and RHEL. Yet you can change the path of files to accommodate your system.