On 8/28/13 10:28 AM, "Stephen Smalley" <[email protected]> wrote:
> >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. Ssh daemon is launched by init.rc but we do have rule to transition it into ssh domain. Likewise, ssh client will be transition to sshClient domain. We don't have rule to distinguish privilege/non privilege client, so privilege is applicable to DAC only. > >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? The test code will be run under sshClient since it is launched under shell. To be honest, I'm not sure there will be problem or not depend on the test case. However, I think if we can transition those test programs out of sshclient into test domain then it may work. However, if the test program needs to communicate with a production code via IPC, it seems like we need to have rules for the production code to communicate with the test code. -- 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.
