On Sun, Jan 02, 2011 at 01:01:11AM -0500, Scott Gifford wrote:
> On Fri, Dec 31, 2010 at 4:19 AM, Dominick Grift <domg472@xxxxxxxxx> wrote:
> [ ... ]
>
> > > 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?
> >
>
> Thanks, that is a good idea, I tried it out and am not getting so many
> warnings in my audit.log. I am concerned they may just be suppressed
> though; when I look at policies for system_mail_t by running:
>
> sesearch -a -s system_mail_t
>
>
> I see lines like this:
>
> dontaudit system_mail_t httpd_t : file { ioctl read getattr lock };
> dontaudit system_mail_t httpd_t : tcp_socket { read write };
That is true. The dontaudit rules silently hide denials. This is usually done for good reason. Hide bugs and/ or leaked file descriptors. You can however unload these hidden denials by running "semodule -DB" This command will rebuild the policy with all the "dontaudit" rules removed. You can re-insert the dontaudit rules by running "semodule -B"
>
>
> Since I am currently running in permissive mode, those lines seem like they
> would mask the problem without solving it. Maybe I will need to set up a
> dev server to test this.
That may well be. Just build policy without the "dontaudits" to test, Do not forget to re-insert the "dontaudits after you are done testing.
> [ ... ]
>
> > > > 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
> >
>
> Thanks, that is a great tool I did not know about!
>
> So here then is an example I am not sure how to troubleshoot.
>
> I don't understand how the mail backend is able to send messages without
> generating AVC denials. "ps -efZ" shows qmail-send, qmail's main backend
> process, and qmail-rspawn, which handles remote messages, as running with
> type "init_t". That makes sense, since they are started by a sequence that
> begins with init(8) and don't transition to any other context. To send the
> mail, it needs to read the configuration files, which are labeled
> "etc_mail_t", and read and write queue files labeled "mqueue_spool_t". It
> shouldn't have permission to do anything with those files:
>
> $ sesearch -a -s init_t |egrep 'etc_mail|mqueue'
> $
>
>
> But somehow it does, or at least seems to to it without generating any AVC
> denials.
>
> Since this is succeeding, there's nothing in the audit.log, and from my own
> inspection the contexts shouldn't allow this. If I were programming I would
> use a debugger or strace(1) to figure out exactly what is going on, but I'm
> not sure if there is an equivalent tool here, or what my options are apart
> from staring at the same information and hoping for insight.
>
Welcome to the concept of attributes. Attribute are strings that group types. By grouping types you can define policy that applies to a group of types instead of a single type.
you can see to what types a attribute is assigned with the seinfo command:
seinfo -x -adomain
You can also use sesearch and attributes
sesearch -SC --allow -s domain -t file_type
In your example above you are probably egrepping for the wrong things. Maybe any of the types you were grepping for themselves arent allowed but attributes they have assigned are.
> [ ... ]
>
> > > 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?
> >
>
> For example, early on in trying out a qmail policy, I forgot this line:
>
> domain_type(mail_qmail_queue_t)
Same idea. This interface assigns the domain attribute to the given parameter (mail_qmail_queue_t).
policy is defined that applies to the domain attribute (all types that have the domain attribute assigned)
This could such an related rule (not sure though:) (from policy/modules/kernel/domain.te):
> The policy compiled fine, but when I tried to load it I got these errors:
>
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> mail_qmail_queue_t sendmail_t:process { sigchld };
neverallow ~{ domain unlabeled_t } *:process *;
basically it says that everything that is not a "domain" or unlabeled_t is not allowed to interact with any process
And so if your mail_qmail_queue_t (which isnt a domain and neither unlabelled_t) tries to send a chld singal to some "process" (sendmail:process) then there a violation because theres a rule that says to never allow it. (basically a way to force you to use the domain attribute.)
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> mail_qmail_queue_t httpd_sys_script_t:process { sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> mail_qmail_queue_t httpd_t:process { sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> mail_qmail_queue_t mail_qmail_queue_t:process { transition sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> mail_qmail_queue_t unconfined_t:process { sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> sendmail_t mail_qmail_queue_t:process { transition sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> httpd_sys_script_t mail_qmail_queue_t:process { transition sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> httpd_t mail_qmail_queue_t:process { transition sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> unconfined_t mail_qmail_queue_t:process { transition sigchld };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> sendmail_t mail_qmail_queue_t:process { transition };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> httpd_sys_script_t mail_qmail_queue_t:process { transition };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> httpd_t mail_qmail_queue_t:process { transition };
> - libsepol.check_assertion_helper: assertion on line 0 violated by allow
> unconfined_t mail_qmail_queue_t:process { transition };
> - libsepol.check_assertions: 13 assertion violations occured
> - libsemanage.semanage_expand_sandbox: Expand module failed
> - semodule: Failed!
>
> Eventually after staring at it awhile, a bit of googling, and some lucky
> guesses I was able to figure it out.
I above explained the concept of attributes. we discussed the dontaudit statement and i quickly showed you the neverallow statement. These are pretty important concepts.
Try to understand these by keeping in mind what i said, and studying the reference polic source policy. See if you can translate some of what i showed above into some thing that makes sense by stuying the actual policy.
And ofcourse if anything is not clear feel free to ask for clarification.
> Are there any tools or guidelines that can help with these sorts of things?
>
> Thanks again for all of your help!
>
> -----Scott.
Attachment:
pgp1xiNpOSH3b.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
