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
- grep
- exec diagnostic tools
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.
