-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/31/2010 06:41 AM, Scott Gifford wrote:
> On Thu, Dec 30, 2010 at 3:55 AM, Dominick Grift <domg472@xxxxxxxxx> wrote:
>
>>
>> On 12/30/2010 08:27 AM, Scott Gifford wrote:
>>
>>> I could write policy to allow mail_qmail_queue access to these httpd_t
>>> resources, but in general it should not have that access; only when it is
>>> run from Apache. I could create a special type for "qmail-queue run from
>>> Apache", but that quickly gets out-of-hand if I create custom policies
>> for
>>> each program that sends mail. What is the normal way to deal with these
>>> sorts of situations?
>>
>> You can silently deny access vectors. So if you know that denying this
>> access does not cause any loss in functionality then consider silently
>> denying some of this.
>
>
>> Anything else, i guess, will just have to be allowed.
>>
>
> I do want to allow them, so that errors and other output will end up
> somewhere.
>
> 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.
>
> 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.
>
> 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?
>
> Maybe it makes sense to run the mail server backend in unconfined_t? That
> seems risky in its own way.
Why not use the mta module policy for your qmail other mtas also run in
this domain. i guess yoou could simply label qmail executable file
sendmail_exec_t?
The current mta policy probably has been tested well.
Or you could use that and other examples to get inspired for yuor own
policy (study how mta deals with similar issues)
> [ ... ]
>
> > Third, is there a useful guide for troubleshooting SELinux policy
>> execution?
>>> When things don't work as I expect them to, it's hard to find the reason
>> if
>>> it's not obvious from the audit.log.
>>
>> Examples?
>>
>> It usually boils down to analyzing AVC denials.
>>
>
> 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.
stuff only transitions if you tell it to transition.
you can also use sesearch to see where your domain is allowed to transition:
example:
sesearch --allow -SC -s ntpd_t -t domain -c process -p transition
<nothing resturned>
means that ntpd_t cannot domain transition
or:
sesearch --allow -SC -s staff_irssi_t -t domain -c process -p transition
Found 1 semantic av rules:
allow staff_irssi_t staff_t : process { transition sigchld } ;
means that staff_irss_t can transition to staff
then you can see what it can execute (file transitions happen on exec:
sesearch --allow -SC -s staff_irssi_t -t exec_type -c file -p execute
Found 3 semantic av rules:
allow staff_irssi_t bin_t : file { read getattr execute open } ;
allow staff_irssi_t irssi_exec_t : file { ioctl read getattr lock
execute entrypoint open } ;
allow staff_irssi_t shell_exec_t : file { read getattr execute open } ;
then you can narrow it down even further:
sesearch --allow -SC -s staff_irssi_t -t bin_t --type
Found 3 semantic av rules:
allow staff_irssi_t bin_t : file { read getattr execute open } ;
allow staff_irssi_t bin_t : dir { ioctl read getattr lock search
open } ;
allow staff_irssi_t bin_t : lnk_file { read getattr } ;
Found 1 semantic te rules:
type_transition staff_irssi_t bin_t : process staff_t;
Means that if staff_irssi_t runs a file with bin_t it transitions to
staff_t.
You could check this for irssi_exec_t, and shell_exec_t.
>
> 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.
examples?
> [ ... ]
>
>> I will try however to answer any specific questions you may have.
>>
>
> Thanks, I appreciate your help and your offer of more help in the future!
> :-)
>
> -----Scott.
>
>
>
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0doAoACgkQMlxVo39jgT/SNwCgyyRMRVJhb1T7tg2jxy6DMZ/Z
5v0An2FB6UosUbAUb7Kykk3CL/eBIO29
=8J1N
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
