On Thu, Apr 20, 2017 at 09:05:59PM +0800, Jason Zaman wrote:
> On Wed, Apr 19, 2017 at 02:12:36PM +0100, Robert Sharp wrote:
[...]
> > One possibility is that it got into this context when my interface went
> > down and up again. I had a problem last night with my Virgin fibre modem
> > and I noticed that after the inevitable hardware reset, a bunch of
> > services had been restarted. Besides the issue that dnsmasq is not bound
> > to the interface in question, I guess I could test it quite easily,
> > although I am not sure everyone else on the LAN will be too keen.
>
> Resolvconf is a thing that handles your /etc/resolv.conf file if many
> interfaces have stuff and would otherwise clobber each other. I assume
> you are using dnsmasq as a local caching resolver on your machine?
> What probably happened is your internet went down then up, you got new
> DNS servers so resolv.conf updated the settings then reloaded/restarted
> dnsmasq. We may be missing a transition from resolvconf_t to dnsmasq_t
>
> # sesearch -T -s resolvconf_t
> type_transition resolvconf_t initrc_exec_t:process initrc_t;
> type_transition resolvconf_t rc_exec_t:process initrc_t;
> type_transition resolvconf_t var_run_t:dir resolvconf_var_run_t;
> type_transition resolvconf_t var_run_t:file resolvconf_var_run_t;
>
> # sesearch -T -t dnsmasq_exec_t
> type_transition NetworkManager_t dnsmasq_exec_t:process dnsmasq_t;
> type_transition initrc_t dnsmasq_exec_t:process dnsmasq_t;
> type_transition virtd_t dnsmasq_exec_t:process dnsmasq_t;
>
> There is no type_trans from resolvconf_t to dnsmasq_exec_t, i'll add it
> to the next version of the policies
Also, one way to potentially facilitate debugging of (non)transitioning, is
to enable auditing on the transitions themselves, and perhaps on the
execute_no_trans (although that one you should do too broadly because it is
triggered many times).
auditallow domain domain:process transition;
Wkr,
Sven Vermeulen
