On 08/28/2013 10:37 AM, Tai Nguyen (tainguye) wrote: > > > 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.
Unless you intend to ship ssh on production devices, why can't ssh/sshClient just be unconfined? -- 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.
