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
