Mailing List Archive: Dnsmasq starts in wrong context after interface cycling?

Dnsmasq starts in wrong context after interface cycling?

Apr 19, 2017, 6:12 AM

Post #1 of 3 (1015 views)

I had a problem with Dnsmasq that led to my last post on understanding
where policies come from. Now that I know and have had dnsmasq
comfortably running with udp comms to unbound on port 553, I have run
into the original problem that I thought I had caused.

I suppose I did cause it, but not in the way I imagined. I was awash
again with AVCs from dnsmasq, but this time I took a closer look and
realised the source context was not as expected. Instead of running in
dnsmasq_t, it was running in resolvconf_t. I checked the binary and that
was as expected so I restarted using run_init just to see if that was
the problem, and it was! So now dnsmasq is running in the correct
context, but how did it ever get to resolvconf_t? Surely if I had
restarted it without using run_init then it would have been in sysadm_t?

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.

Any thoughts welcome

Robert Sharp

Re: Dnsmasq starts in wrong context after interface cycling? [ In reply to ]

perfinion at gentoo

Apr 20, 2017, 6:05 AM

Post #2 of 3 (1011 views)

Permalink

On Wed, Apr 19, 2017 at 02:12:36PM +0100, Robert Sharp wrote:
> I had a problem with Dnsmasq that led to my last post on understanding
> where policies come from. Now that I know and have had dnsmasq
> comfortably running with udp comms to unbound on port 553, I have run
> into the original problem that I thought I had caused.
>
> I suppose I did cause it, but not in the way I imagined. I was awash
> again with AVCs from dnsmasq, but this time I took a closer look and
> realised the source context was not as expected. Instead of running in
> dnsmasq_t, it was running in resolvconf_t. I checked the binary and that
> was as expected so I restarted using run_init just to see if that was
> the problem, and it was! So now dnsmasq is running in the correct
> context, but how did it ever get to resolvconf_t? Surely if I had
> restarted it without using run_init then it would have been in sysadm_t?
>
> 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

-- Jason

Re: Dnsmasq starts in wrong context after interface cycling? [ In reply to ]

swift at gentoo

Apr 20, 2017, 7:42 AM

Post #3 of 3 (1011 views)

Permalink

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