On Thu, Nov 29, 2012 at 6:36 AM, Stephen Smalley <[email protected]> wrote: > On 11/29/2012 08:53 AM, Tai Nguyen (tainguye) wrote: >> >> For enterprise devices, we need to be able to support our customer >> troubleshooting issues. >> Thus, we need to have shell access to do exploring tasks like >> - ps You can use the Android SDK to get a list of processes >> - grep Isn't even on the device >> - exec diagnostic tools Standard Android debugging tools work, with NDK gdb debugging support recently being addressed (still WIP AFIK) >> >> However, we have different independent teams working on the products and >> they, except security team, are not aware of security policies. Likewise, >> security team will not know all the changes made by other teams (e.g., >> troubleshooting tools) to maintain the policies. >> >> So, we are looking for a solution that minimize the dependencies across >> teams and minimize the burden of security policy to other development >> teams. > > > Do you expect customers to use an adb shell to troubleshoot issues? Or is > this a shell spawned by some management app on the device? Those would run > in different domains. > > You would need define a bit more of what you want to be possible from these > shells. For example, do you truly require complete visibility of all > processes, including root daemons, or just some subset like running apps? > Do you truly require the ability to search and read every file, or can you > define a searchable subset? What do the diagnostic tools need to be able to > do? > > I expect the security team would have to create an initial policy based on > current practices and tools, based on whatever testing is already done as > part of your QA process. Then over time it would become a shared > responsibility across the teams to maintain the policy - the other teams > would at least understand how to check whether SELinux is interfering with > their product's operation and how to report that to the security team, and > over time would improve their own understanding and be increasingly able to > diagnose and address issues as they arise. Not sure it is all that > different from Red Hat's situation with their security team and their > various package maintainers. > > You also have the option of initially shipping with the shell as a > permissive domain, as Joshua described, in which case everything will be > allowed but denials will be logged. If you ensure that you have a mechanism > for collecting those denials, then you can incrementally adapt the policy > until you have no further reports of such denials, and then drop the > permissive domain declaration from the policy in the next product cycle. > > > > > -- > 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.
-- Respectfully, William C Roberts -- 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.
