On Thu, Dec 30, 2010 at 3:55 AM, Dominick Grift <span dir="ltr"><<a href="mailto:domg472@gmail.com">domg472@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="h5"><br>
On 12/30/2010 08:27 AM, Scott Gifford wrote:<br><br>
> I could write policy to allow mail_qmail_queue access to these httpd_t<br>
> resources, but in general it should not have that access; only when it is<br>
> run from Apache. I could create a special type for "qmail-queue run from<br>
> Apache", but that quickly gets out-of-hand if I create custom policies for<br>
> each program that sends mail. What is the normal way to deal with these<br>
> sorts of situations?<br>
<br>
</div></div>You can silently deny access vectors. So if you know that denying this<br>
access does not cause any loss in functionality then consider silently<br>
denying some of this. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Anything else, i guess, will just have to be allowed.<br></blockquote><div><br></div><div>I do want to allow them, so that errors and other output will end up somewhere.</div><div><br></div><div>I'm having a hard time seeing how this process can be reasonably managed. It is probably impossible for me to predict in advance the types of all of the things that could end up connected to the qmail-queue's filehandles. A message could be created in a temporary file and sent that way, or sent from a pipe in a cronjob, etc. Similarly its output could be sent to a temp file, log file, etc. There are hundreds of possible combinations that should be allowed. It seems that I would have to monitor the audit log, carefully investigate exceptions, and modify the policy periodically. But this is very high-risk for mail, since a new combination of events that triggers a new AVC denial and blocks the message could be some exceptional event I want an email about, like smartd trying to send me a message saying my hard drives are failing.</div>
<div><br></div><meta charset="utf-8"><div>It seems like sendmail would have to deal with these same sorts of issues, but I don't see anything in sendmail.if that seems to address them.</div><div><br></div><div>Is there some better way to manage this process or write policies that are a bit more flexible, like a wildcard? Or is some educated guesswork and long-term monitoring of the AVC denials my only option?</div>
<div><br></div><div>Maybe it makes sense to run the mail server backend in unconfined_t? That seems risky in its own way.</div><div><br></div><div>[ ... ]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> Third, is there a useful guide for troubleshooting SELinux policy execution?<br>
> When things don't work as I expect them to, it's hard to find the reason if<br>
> it's not obvious from the audit.log.<br>
<br>
</div>Examples?<br>
<br>
It usually boils down to analyzing AVC denials.<br></blockquote><div><br></div><div>I may be able to find what I need in the AVC logs. I think I'm just not yet confident enough that my policies work as they should, and it would be reassuring to see the domain transitions as they run.</div>
<div><br></div><div>I have had some problems with failed assertions, which have far too little debug information to troubleshoot them with anything but guesswork, but that's probably a separate issue.</div><div><br></div>
<div>[ ... ] </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I will try however to answer any specific questions you may have.<br></blockquote><div><br></div><div>
Thanks, I appreciate your help and your offer of more help in the future! :-)</div><div><br></div><div>-----Scott.</div><div><br></div></div>