SELinux C7 Audit

Home » CentOS » SELinux C7 Audit
CentOS 2 Comments

Hi list, I’m studying SELinux on my workstation and for this I’ve enforced. In a first time selinux was permissive and when switched to enforcing I
had relabel some things. Due to my “nescience” about selinux and what I must configure, I’m waiting avc denied for specified services.

Until today, I’ve configured successfully httpd, smbd. Today I’ve noticed that my bacula system does not work due to selinux denied because when bacula try to run pre/post job script I get access denied due to differences about context.

Bacula is on bacula_t and in pre script I call commands in other context like:

systemd_systemctl_exec_t
… (and other)

Reading from RHEL DOC (SELinux Guide) I can accomplish to remove denied access using audit2allow and creating TE rules.

I’ve runned:

grep systemctl /var/log/audit/audit.log | audit2allow -M pol

and I got 2 files pol.pp (compiled) and pol.te.

pol.te reports:

require {
type systemd_systemctl_exec_t;
type bacula_t;
class file execute;
}

#============= bacula_t =============allow bacula_t systemd_systemctl_exec_t:file execute;

Loading this policy things “will work”.

Now this problem is solved by audit2allow and not by me. I don’t know what is necessary to make pre/post job script to get work done.

What are the meaning of rules on pol.te and why bacula can’t do transiction between context?

Hope in help.

Thanks in advance.

2 thoughts on - SELinux C7 Audit

  • https://wiki.CentOS.org/HowTos/SELinux The CentOS howto has some information, and links to additional resources.

    The policy should be pretty easy to read, though. You have one rule,
    “allow bacula_t systemd_systemctl_exec_t:file execute.” Each word in that rule, except for “allow” is defined somewhere, and has to be loaded, so they are each individually loaded in the “require” block.

    The easiest way to write a policy is to apply labels and run an application in permissive mode. Using the AVCs that are logged, a new policy can be generated. The short answer is, you’re doing something that the people who developed the SELinux policy didn’t do while writing the policy. If the thing that you’re doing is standard or best practice, you might consider that a bug and file a report to have the policy extended. However, I suspect that restarting services is not a standard practice, so the local policy that you’ve generated is the best solution.