On 08/28/2013 10:19 AM, Tai Nguyen (tainguye) wrote: > 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.
So, if I understand correctly, the ssh daemon is launched by init.rc and as we don't define a domain for it in policy, it will be run in the init domain by default (stays in the caller's domain unless there is a domain transition). As init is unconfined in the policy, this means that sshd and all of its children will run unconfined by default, and thus there will be no restrictions on the test programs. So that seems to "work" for your scenario so long as the actual production code that you want to test in a confined domain is launched from other services, not directly spawned from the ssh shell, and the only thing that runs in the ssh shell is the test code that you don't want to restrict. Or am I missing something? -- 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.
