On 8/28/13 9:00 AM, "Stephen Smalley" <[email protected]> wrote:
>On 08/27/2013 02:12 PM, Tai Nguyen (tainguye) wrote: >> All, >> >> We are looking for recommendation to support incremental automation >>test for SEAndroid device. Since it is expected that developers will add >>automation tests and those tests are run automatically on the device for >>every build, having the policies to support those unknown test programs >>is a challenge. >> >> I think SEAndroid can handle test apk pretty well However, we are not >>sure about native (Linux) test programs. It seems that we may need to >>add rules to transition these test programs to right domain. So, it >>seems that the whole development team need to create rules for test >>programs. This is not desirable because these test rules may end up in >>release/official loads. In addition, the team may not have SEAndroid >>knowledge to create right rules. >> >> We really appreciate if you can provide us your feedback or >>recommendation. > >When you say "native (Linux) test programs", do you mean: >a) such programs executed from a regular (unprivileged) adb shell, >b) such programs executed from an adb shell after an adb root or via su, >c) such programs executed from an app Since the goal is to run the tests automatically after a build is complete, we use ssh to get a shell on the device (i.e., no human interaction). The shell can be privilege on non privilege based on login. Then the tests are executed from the shell. > >Do the test programs do things that you don't want to permit on >production devices? Or are they testing functionality that should in >fact work on production devices? Because the goal is to test the code on the device, not the test code, we don't need to restrict access to test code. Similarly, the test code goal is to test the production code in production devices, so the work should be done by the production code and not the test code. In other words, the test code setup the test scenario then trigger the production code to run in that environment. We think that we can put test program in no-constraint group, however, it is unclear how do we transition those programs into that domain given that we don't want to pollute policy with these test program rules. We have different and independent development team working on the device, and most of the team do not have knowledge of SELinux policy, so it is undesirable to ask each team to write policy for their test case. Also, it is also undesirable to write too many rules for test programs. Let me share some background information as well We have different category of automation test (e.g., unit test, component test, integration test). Low level tests (unit test, component test) can be done offline (i.e., not on device). High level tests (e.g., integration test) are done on the device but should not use mock or stub object. So, the tests in this discussion are high level tests. -- 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.
