So I looked into some abandoned patches I had in my repo and non of them
were applicable, or really any good :-P. I really think the cleanest way to
solve this is just set seclabel for anything that uses logwrapper. That way
you avoid the compute context issue.
FYI P2P and WPA share a binary, like ueventd and initd do.
The denial your seeing is service p2p_supplicant not wpa_supplicant, they
share the binary. I printed out the setsocketcon, you can see its getting
set to
init <3>[ 10.927697] init: BILL Setting socket con for p2p_supplicant with
u:r:init:s0
After the patch
<3>[ 11.092385] init: BILL Setting socket con for p2p_supplicant with
u:r:wpa:s0
If you apply this patch the denial:
type=1400 msg=audit(2356128.534:95): avc: denied { write } for pid=589
comm="wpa_supplicant" path="/dev/socket/wpa_wlan0" scontext=u:r:wpa:s0
tcontext=u:r:init:s0 tclass=unix_dgram_socket
goes away.
However, A few creep up on logwrapper not marked with the exec attribute I
don't know enough yet to determine if p2p should get its own domain or not.
Apply this patch to your mako init.rc to reproduce
diff --git a/init.mako.rc b/init.mako.rc
index 93b0b40..48a0e94 100644
--- a/init.mako.rc
+++ b/init.mako.rc
@@ -323,6 +323,7 @@ service wpa_supplicant /system/bin/logwrapper
/system/bin/wpa_supplicant \
# after setting up the capabilities required for WEXT
# user wifi
# group wifi inet keystore
+ seclabel u:r:wpa:s0
class main
socket wpa_wlan0 dgram 660 wifi wifi
disabled
@@ -336,6 +337,7 @@ service p2p_supplicant /system/bin/logwrapper
/system/bin/wpa_supplicant \
# after setting up the capabilities required for WEXT
# user wifi
# group wifi inet keystore
+ seclabel u:r:wpa:s0
class main
socket wpa_wlan0 dgram 660 wifi wifi
disabled
On Wed, May 8, 2013 at 5:57 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
> On 05/08/2013 01:58 AM, William Roberts wrote:
>
>> 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...
>>
>
> Different object, different security context.
> Unix/local domain sockets have two objects associated with them: the
> socket itself (labeled with the security context of the creating process)
> and the file used to name the socket (labeled with a file security
> context). The file_contexts entry is only for the latter, not the former.
>
>
>
--
Respectfully,
William C Roberts
