On Mon, Feb 9, 2015 at 3:46 PM, Joshua Brindle <brin...@quarksecurity.com> wrote:
> William Roberts wrote: > >> >> >> On Mon, Feb 9, 2015 at 3:24 PM, Joshua Brindle >> <brin...@quarksecurity.com <mailto:brin...@quarksecurity.com>> wrote: >> >> William Roberts wrote: >> >> >> >> On Mon, Feb 9, 2015 at 1:50 PM, Dong Zhou <dong.z...@gm.com >> <mailto:dong.z...@gm.com> >> <mailto:dong.z...@gm.com <mailto:dong.z...@gm.com>>> 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? >> >> As Stephen stated, "Presently the only way to do it is to copy the >> system_app.te rules into >> a new domain .te file and just rename system_app to your new >> domain >> name. If you wanted to do it more easily, you could take the >> system_app.te rules to a macro defined in te_macros and then >> call that >> macro from multiple .te files, or define a new attribute, change >> the >> system_app.te rules to use that new attribute instead of >> system_app, and >> assign system_app and your new domains to that attribute." >> I think most of this is preference, I typically do the attribute >> approach. Ill create a system_app_domain attribute and then take >> all >> the allow system_app rules and change them to allow >> system_app_domain. >> Then from tere, attribute system_app to the >> system_app_domain. Then, the use that attribute in the new domain >> as >> well. I think this is the most "pure approach". Also, >> *i think* this ends up being the smallest binary representation of >> policy size as well; but don't quote me on that, I could be wrong. >> >> >> The main issue with this is if system_app_domain is used as a target >> then you'll be granting access to both system_app and your new type. >> This may not be an issue for a particular use-case/threat model but >> it could be. >> >> >> No, not at all. You only add the additional rules to the new domain... >> >> all the system_app "allow rules" get added to an attribute >> system_app_domain >> >> type system_app, system_app_domain; >> >> type newdomain, system_app_domain; >> >> allow newdomain ... >> >> > Yes, I understand what you were suggesting. I'm saying that it can lead to > unintentional rules if you don't correctly factor out anything where > system_app was previously a target. You also need to factor out any > system_data_file rules and add those separately. After doing all that it > may or may not be better than making a macro that has all the rules. > Yes the target case depends on their exact usage. Assuming they want a perfect superset then the target "allows" would also be subject to the new attribute thus allowing both existing system_app and newdomain to be a target for things, like ipc. This may or may not be what they intend. > > >> >> >> >> My preference is to turn it into a macro and make new types that >> way. There are advantages both ways. You are correct about it being >> a smaller representation above. The attributes are only expanded if >> there is a -type in a rule (to subtract a type from an attribute). >> >> >> thanks again >> >> Joe >> __________________________________________ >> From: Stephen Smalley <stephen.smal...@gmail.com >> <mailto:stephen.smal...@gmail.com> >> <mailto:stephen.smalley@gmail.__com >> <mailto:stephen.smal...@gmail.com>>> >> Sent: Monday, February 09, 2015 7:44 AM >> To: Dong Zhou >> Cc: seandroid-list@tycho.nsa.gov >> <mailto:seandroid-list@tycho.nsa.gov> >> <mailto:seandroid-list@tycho.__nsa.gov >> <mailto: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 >> <mailto:dong.z...@gm.com> >> <mailto:dong.z...@gm.com <mailto: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 >> <mailto:Seandroid-list@tycho.nsa.gov> >> <mailto:Seandroid-list@tycho.__nsa.gov >> <mailto:Seandroid-list@tycho.nsa.gov>> >> > To unsubscribe, send email to >> Seandroid-list-leave@tycho.__nsa.gov >> <mailto:seandroid-list-le...@tycho.nsa.gov> >> <mailto:Seandroid-list-leave@__tycho.nsa.gov >> <mailto:seandroid-list-le...@tycho.nsa.gov>>. >> > To get help, send an email containing "help" to >> > Seandroid-list-request@tycho.__nsa.gov >> <mailto:seandroid-list-requ...@tycho.nsa.gov> >> <mailto:seandroid-list-__requ...@tycho.nsa.gov >> <mailto: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 >> <mailto:Seandroid-list@tycho.nsa.gov> >> <mailto:Seandroid-list@tycho.__nsa.gov >> <mailto:Seandroid-list@tycho.nsa.gov>> >> To unsubscribe, send email to >> Seandroid-list-leave@tycho.__nsa.gov >> <mailto:seandroid-list-le...@tycho.nsa.gov> >> <mailto:Seandroid-list-leave@__tycho.nsa.gov >> <mailto:seandroid-list-le...@tycho.nsa.gov>>. >> To get help, send an email containing "help" to >> Seandroid-list-request@tycho.__nsa.gov >> <mailto:seandroid-list-requ...@tycho.nsa.gov> >> <mailto:seandroid-list-__requ...@tycho.nsa.gov >> <mailto:seandroid-list-requ...@tycho.nsa.gov>>. >> >> >> >> >> -- >> Respectfully, >> >> William C Roberts >> >> _________________________________________________ >> Seandroid-list mailing list >> Seandroid-list@tycho.nsa.gov <mailto:Seandroid-list@tycho.nsa.gov >> > >> To unsubscribe, send email to >> Seandroid-list-leave@tycho.__nsa.gov >> <mailto:seandroid-list-le...@tycho.nsa.gov>. >> To get help, send an email containing "help" to >> Seandroid-list-request@tycho.__nsa.gov >> <mailto:seandroid-list-requ...@tycho.nsa.gov>. >> >> >> >> >> >> -- >> Respectfully, >> >> William C Roberts >> >> > -- 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.
