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.

Reply via email to