Their is an issue with using the socket keyword in the init.rc when the
service is started with logwrapper. The resulting socket stays in the init
domain, thus when the child process is finally invoked by logwrapper, it,
most likely, cannot access its socket. An example of this is on the Mako
(Nexus 4) wpa_supplicant service.
I have a patch that I am uploading to Gerrit that lets one specify the
seccontext for sockets. This may
not be the best approach, but is an approach.
Also, ( I have not tested this), one could add the seclabel to the
wpa_supplicant service. This way it won't compute the wrong value.
Why this occurs:
in init.c
the security context for the child process is computed and stored in scon.
Either it uses the value in seclabel, or computes it via the following:
1. get its current context via getcon(&con)
2. get the filecontext of the executable via getfilecon(svc->args[0],
&fcon);
3. Computes the scon via security_compute_create(mycon, fcon,
string_to_security_class("process"), &scon)
4.
The issue arises when the getfilecon returns system_file (as logwrapper has
no unique label)
Since no transition occurs on init --> system_file, the computed context
remains init.
A fork then occurs and the value "init" is then used in
a setsockcreatecon(scon);
Thus the wpa_supplicant socket is labeled as init.
--
Respectfully,
William C Roberts
