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.

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
7
  • 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, 2015 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, 2015 at 17:58
  • I will update and approve the answer once I'm able to verify that it works.
    – UtahJarhead
    Oct 19, 2015 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 .
    – Accountant م
    Jul 13, 2019 at 0:15
  • this is also useful resource
    – Accountant م
    Jul 13, 2019 at 0:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .