On 05/09/2013 02:37 PM, Tai Nguyen (tainguye) 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 disabledInit 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
I think that is a bit overkill, and means that we would duplicate the pathname information in two places, which is just as prone to error.
Look, if the change to handle logwrapper in init isn't considered acceptable and we are going to require the developer to modify init.rc to support logwrapper usage, then let's just go with the original seclabel approach and not worry about it any further. The advantage of this modified seclabel approach is too small to be worth the trouble, as it still imposes developer burden to maintain the additional information in the init.rc and per Bill, we still have to allow entrypoint to logwrapper for the case where the original seclabel option is used with logwrapper entries. So the only benefit of this approach is it avoid encoding the security context string in the init.rc, which seems like a relatively small win to me, not worth the additional complexity and the need to maintain the path consistently in two places (in the service line and in the seclabel line).
I'm done discussing this, let's just modify the policy and move on, please. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
