5

I have a proprietary piece of software my company owns that needs access to a root-level file. We'll call it /secfile as it is security/license related. The system runs a daemon that writes out updated information to /secfile. This daemon, if prevented from updating /secfile, invalidates the license in question because it assumes foul play.

How can I force SELinux to allow the daemon, which resides at /bin/secdaemon, access to /secfile?

The only other application that needs access (which is currently not restricted) to /secfile is /usr/bin/licensemanager.

UtahJarhead
  • 2,027
  • 2
  • 13
  • 15

1 Answers1

11

Well, the easiest way is disabling SELinux, which I don't recommend, though:

setenforce 0

Or you can create a rule to allow it to write, run or whatever it needs to do and is being blocked so far. To do so, check your system log file and copy the line that is "denied", it should be something like this:

audit(...): avc:  denied  { write } for  pid=27984 comm="httpd" name="httpd" dev=sda6 ino=307469 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=...

Copy it and run the following command:

audit2allow -M local << _EOF_
(paste the content)
_EOF_

Then, run:

semodule -i local.pp

That will create a permanent rule for it so you shouldn't need to disable SELinux.

nKn
  • 5,549
  • 6
  • 32
  • 38
  • 1
    Agreed. I've been disabling it on test systems, but with more customers moving to SELinux-enabled machines, they obviously would prefer to leave it enabled. – UtahJarhead Oct 19 '15 at 17:56
  • 2
    Forgot to mention: you can grab and paste **all** the "denied" lines at once, simply end the pasting with the `_EOF_` line and the `audit2allow` command will generate as many rules as needed in the `local.pp` file. – nKn Oct 19 '15 at 17:58
  • I will update and approve the answer once I'm able to verify that it works. – UtahJarhead Oct 19 '15 at 18:45
  • "The default location where you can find this logging depends a bit on the distribution, but generally it is either in /var/log/avc.log if you are not running the Linux audit daemon, and in /var/log/audit/audit.log or /var/log/audit.log if you are. This logging is very verbose, mainly because you need many details in order to troubleshoot problems." [source](https://wiki.gentoo.org/wiki/SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details) . – Accountant م Jul 13 '19 at 00:15
  • this is also [useful resource](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow) – Accountant م Jul 13 '19 at 00:15
  • `grep denied /var/log/audit/audit.log` or whatever the path is – Accountant م Jul 13 '19 at 00:16