I'm diffing some stuff right now, and just noticed something I missed
before....
We are setting the socketcontext above the create_socket() call, but the
create_socket() function
calls a setfscreatecon(scon) based on looking it up in the file contexts,
why don't we just add
in setsocketcreatecon(scon) there as well?
This way the behavior is use the default or whatever is in file_contexts...
Bill
On Tue, May 7, 2013 at 10:37 PM, William Roberts
<bill.c.robe...@gmail.com>wrote:
> 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
>
>
--
Respectfully,
William C Roberts
