Well ';' and ':' '}'and '{' are reserved by the syntax of the language
perhaps seclabel {/system/bin/wpa_supplicant}
On Thu, May 9, 2013 at 3:17 PM, William Roberts <[email protected]>wrote:
> Are their any characters that cannot be used in a security label, that we
> can safely use a delimiter if we went with reusing the seclabel option in
> init.rc for this?
>
>
> On Thu, May 9, 2013 at 3:05 PM, William Roberts
> <[email protected]>wrote:
>
>> Although I am not sure how Google would appreciate that syntax in the
>> init.rc, I can upload mine as is, and then tweak it via review.
>>
>>
>> On Thu, May 9, 2013 at 3:01 PM, William Roberts <[email protected]
>> > wrote:
>>
>>> haha I just read this.. yeah came up with the same thing, just slightly
>>> different expression for it. I think I like your expression better. Do you
>>> have patch for this, I can modify mine
>>>
>>>
>>> On Thu, May 9, 2013 at 11:37 AM, Tai Nguyen (tainguye) <
>>> [email protected]> wrote:
>>>
>>>> A compromised option can be merging Steve's computation with seclabel
>>>>
>>>>> service wpa_supplicant /system/bin/logwrapper
>>>>> /system/bin/wpa_supplicant \
>>>>> # after setting up the capabilities required for WEXT
>>>>> # user wifi
>>>>> # group wifi inet keystone
>>>>
>>>> seclabel pcontext=/system/bin/wpa_supplicant
>>>>>
>>>>> class main
>>>>> socket wpa_wlan0 dgram 660 wifi wifi
>>>>> disabled
>>>>>
>>>>
>>>> Init will compute the security context for seclabel based on the
>>>> input process, thus, ensure that the security context is consistent and the
>>>> option can be used for different scenario as well
>>>>
>>>>
>>>> From: William Roberts <[email protected]>
>>>> Date: Thursday, May 9, 2013 2:20 PM
>>>> To: Stephen Smalley <[email protected]>
>>>> Cc: Tai Nguyen <[email protected]>, "[email protected]" <
>>>> [email protected]>
>>>> Subject: Re: Improper labeling of init created sockets when using
>>>> logwrapper
>>>>
>>>> Yeah I thought about doing exactly what your patch does, but didn't
>>>> like hard-coding "logwrapper", as anyone forking/execing across another
>>>> thing similar to logwrapper will have the
>>>> same issue. I liked it to be consistent.
>>>>
>>>>
>>>> On Thu, May 9, 2013 at 8:00 AM, Stephen Smalley <[email protected]>wrote:
>>>>
>>>>> On 05/09/2013 10:56 AM, Tai Nguyen (tainguye) wrote:
>>>>>
>>>>>>
>>>>>> Steve,
>>>>>>
>>>>>> Thank for clarification. In that case, can we do something like
>>>>>> service wpa_supplicant /system/bin/logwrapper
>>>>>> /system/bin/wpa_supplicant \
>>>>>> # after setting up the capabilities required for WEXT
>>>>>> # user wifi
>>>>>> # group wifi inet keystore
>>>>>> class main
>>>>>> socket wpa_wlan0 dgram 660 wifi wifi context=u:r:wpa:s0
>>>>>> disabled
>>>>>>
>>>>>
>>>>> With my patch, you don't need to specify the socket security context
>>>>> at all; init will compute it correctly.
>>>>>
>>>>> Prior to my patch, you could work around it by adding a seclabel entry
>>>>> for the service, i.e.
>>>>> service wpa_supplicant /system/bin/logwrapper
>>>>> /system/bin/wpa_supplicant
>>>>>
>>>>> seclabel u:r:wpa:s0
>>>>> ...
>>>>>
>>>>> but that would require a policy change to allow entrypoint permission
>>>>> between wpa and the type on the logwrapper program.
>>>>>
>>>>> There is no context= option for socket entries at present, and we
>>>>> don't really need it since we can handle it using either the patch I
>>>>> posted
>>>>> (now also uploaded to AOSP at [1]) or by using the seclabel approach
>>>>> above.
>>>>>
>>>>> [1]
>>>>> https://android-review.**googlesource.com/#/c/58300/<https://android-review.googlesource.com/#/c/58300/>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Respectfully,
>>>>
>>>> William C Roberts
>>>>
>>>>
>>>
>>>
>>> --
>>> Respectfully,
>>>
>>> William C Roberts
>>>
>>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>>
>>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
--
Respectfully,
William C Roberts
