On 28 August 2013 19:16, Dominick Grift <dominick.grift@gmail.com> wrote:
On Wed, 2013-08-28 at 18:53 +0200, Robert Gabriel wrote:

> Please advise.
>
> Any help appreciated, thank you.

There are various things you may have overlooked:

Some things may be silently denied, thus not showing up in the audit.log
by default

To expose these, follow this procedure:

semodule -DB
reproduce issue
look for avc, user_avc and selinux_err messages in audit.log, and
in /var/log/messages
semodule -B

Make sure you arent overlooking selinux messages. Sometimes SELinux logs
to /var/log/messages but most of the time to /var/log/audit/audit.log

But if you use ausearch to parse the audit.log then use "-m
avc,user_avc,selinux_err", so that it looks for all kinds of selinux
related messages  rather than only regular "avc denials"

When writing policy , one usually needs to do various rounds of testing
because not all issues may surface the time round of testing

Heres the procedure i usually follow ( in that order ):

1. test in permissive mode
2. test in permissive mode with semodule -DB
3. test in enforcing mode with semodule -DB
4. test in enforcing mode

Principles of Information Security


Those are just some suggestions, but since i have little information
about your issues it is hard to determine if this will help

Some questions:

1. does it work in permissive mode?
2. does or do the processes run in the expected context(s)
3. can you enclose your source policy module for review?

Thank you!

I will look into the above tomorrow at the office, I wasn't aware of looking at other messages.

1. Yes, it runs fine in permissive mode.

2. Yes, the processes are in the expected context.

3. Yes, I can. Pardon my ignorance, but you will then need *.fc, *.te, *.if, *.sh files yes?

Thank you again, I can't wait to carry on getting to this tomorrow, I'll advise ASAP.