On Tue, Feb 10, 2015 at 5:38 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
> On 02/09/2015 04:50 PM, Dong Zhou wrote: > > Hi, Stephen > > > > Thanks bunch for your reply. Suppose if we really have special > permission requirements, what should be the "right" way to do that? > > I suppose I should clarify further. If you are just creating policy > specific for your device (and therefore only adding policy under > device/<vendor>/<product>/sepolicy), then you should just define your > own new domain under that directory, copying the appropriate rules from > system_app.te or whatever domain you are using as your basis. If we > wanted to support this more easily in the future in AOSP policy, then we > would either define macros or attributes so that the rules could be > inherited without needing to manually copy them. > > Jinlin's observation that copying the system_app rules will likely cause > neverallow failures is correct, as system_app is specially privileged > and neverallow rules prohibit any other domain from having certain > permissions. So you would either need to remove those rules from your > new domain or seek to get the neverallow rules adjusted in AOSP policy > to avoid a CTS failure. > > When you encounter neverallow rules, they can often times be resolved by a simple relabel of the target. For instance, if no other domain but system_app can write to system_app_data_file, and your new domain tries to access it, it will likely through a neverallow. This is all hypothetical, I did not check the base policy for this neverallow, but it likely exists. Anyways, one can just relabel that to some new type of file and share it between the domains. However, this sometimes can cause issues when things are wildcarded in neverallows. In this case, then investigating if the rules should be relaxed makes sense. This seems to be a common paradigm, needing to "extend" a base class. copying is not cool IMO, you dont copy and paste code around, you make a function or for the oop crowd, extend some base. Perhaps, we should visit attributing the appdomains to make this extension less painfil. However, I would reccomend getting buy in from Nick or someone at Google first, as this is a large architectural change to the policy. > > > > thanks again > > > > Joe > > ________________________________________ > > From: Stephen Smalley <stephen.smal...@gmail.com> > > Sent: Monday, February 09, 2015 7:44 AM > > To: Dong Zhou > > Cc: seandroid-list@tycho.nsa.gov > > Subject: Re: To allow custom domain to extend system_app type (SEAndroid) > > > > One caveat I would note is that you should not define new app domains > > unless they truly have unique permission requirements. Domains are > > equivalence classes. > > > > On Mon, Feb 9, 2015 at 1:07 AM, Dong Zhou <dong.z...@gm.com> wrote: > >> Hi, there > >> > >> > >> Sorry for this entry level question. > >> > >> > >> In SEAndroid AOSP release, I understand domain and appdomain are > attributes, > >> then you can define types inherit the access permissions from them. > >> Actaully, system_app, platform_app and untrusted_app are all using > macros to > >> inherit from appdomain attribute. My question is, if we want to define > my > >> customer domains, some inherit from system_app, some from platform_app > or > >> untrusted_app. But since those are already defined as types, how can I > >> extend an existing type instead of an attribute? > >> > >> > >> What is the recommended way to handle this? > >> > >> > >> thanks a lot! > >> > >> > >> Joe > >> > >> > >> > >> > >> > >> Nothing in this message is intended to constitute an electronic > signature > >> unless a specific statement to the contrary is included in this message. > >> > >> Confidentiality Note: This message is intended only for the person or > entity > >> to which it is addressed. It may contain confidential and/or privileged > >> material. Any review, transmission, dissemination or other use, or > taking of > >> any action in reliance upon this message by persons or entities other > than > >> the intended recipient is prohibited and may be unlawful. If you > received > >> this message in error, please contact the sender and delete it from your > >> computer. > >> > >> _______________________________________________ > >> Seandroid-list mailing list > >> Seandroid-list@tycho.nsa.gov > >> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. > >> To get help, send an email containing "help" to > >> seandroid-list-requ...@tycho.nsa.gov. > > > > > > Nothing in this message is intended to constitute an electronic > signature unless a specific statement to the contrary is included in this > message. > > > > Confidentiality Note: This message is intended only for the person or > entity to which it is addressed. It may contain confidential and/or > privileged material. Any review, transmission, dissemination or other use, > or taking of any action in reliance upon this message by persons or > entities other than the intended recipient is prohibited and may be > unlawful. If you received this message in error, please contact the sender > and delete it from your computer. > > > > _______________________________________________ > > Seandroid-list mailing list > > Seandroid-list@tycho.nsa.gov > > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. > > To get help, send an email containing "help" to > seandroid-list-requ...@tycho.nsa.gov. > > > > > > _______________________________________________ > Seandroid-list mailing list > Seandroid-list@tycho.nsa.gov > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. > To get help, send an email containing "help" to > seandroid-list-requ...@tycho.nsa.gov. > -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
