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) <taing...@cisco.com>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 <bill.c.robe...@gmail.com> > Date: Thursday, May 9, 2013 2:20 PM > To: Stephen Smalley <s...@tycho.nsa.gov> > Cc: Tai Nguyen <taing...@cisco.com>, "seandroid-list@tycho.nsa.gov" < > seandroid-list@tycho.nsa.gov> > 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 <s...@tycho.nsa.gov> 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
