On Fri, Jan 10, 2014 at 10:41 AM, Stephen Smalley <[email protected]> wrote: > On 01/10/2014 01:39 PM, William Roberts wrote: >> On Fri, Jan 10, 2014 at 10:30 AM, Stephen Smalley <[email protected]> wrote: >>> On 01/10/2014 01:20 PM, William Roberts wrote: >>>> Id be ok with that assuming we add support to mac_perms for prefix >>>> matching... >>>> >>>> Off the top of my head I recall seeing some applications during >>>> running invoke services >>>> that run as separate process but do not have the isolated uid range. >>>> Prefix matching in >>>> seapp_contexts was a big help with getting everything into the right >>>> domain. I typically >>>> only use key in mac_permissions.xml. >>>> >>>> >>>> As an example, if you run firefox like so: >>>> >>>> user=_app name=org.mozilla.firefox seinfo=mozilla domain=untrusted_app >>>> type=app_data_file level=s0:c1 >>>> user=_app name=org.mozilla.firefox.seinfo=mozilla UpdateService >>>> domain=untrusted_app type=app_data_file level=s0:c1 >>>> user=_app name=org.mozilla.firefox.PasswordsProvider seinfo=mozilla >>>> domain=untrusted_app type=app_data_file level=s0:c1 >>>> >>>> You can preifx match like so: >>>> user=_app name=org.mozilla.firefox* domain=untrusted_app >>>> type=app_data_file level=s0:c1 >>> >>> That entry would be unsafe as it does not specify seinfo= and therefore >>> is not bound to any signing certificate, and any apk can choose to use a >>> org.mozilla.firefox prefix. >> >> yes it would.. hence its just an example to demonstrate what I am talking >> about more clearly.. see where I don't condone these entries as is below. >> So anyone reading this.. make sure you always add seinfo if specifying >> custom domains or levels. >> >>> >>>> Or if you really wanted to get crazy: >>>> user=_app name=org.mozilla.firefox seinfo=mozilla domain=untrusted_app >>>> type=app_data_file level=s0:c2 >>>> user=_app name=org.mozilla.firefox.seinfo=mozilla UpdateService >>>> domain=untrusted_app type=app_data_file level=s0:c3 >>>> user=_app name=org.mozilla.firefox.PasswordsProvider seinfo=mozilla >>>> domain=untrusted_app type=app_data_file level=s0:c4 >>>> >>>> This is really just something I made up. Currently its possible, >>>> doesn't mean I'm endorsing it. However, the separate >>>> launches of firefox, and matching input selectors are real. >>>> >>>> My concern is, if we match in PMS with mac_perms.xml and drop >>>> seapp_contexts, we would lose the ability to do the crazy scenario >>>> as PMS only sees: >>>> package="org.mozilla.firefox" >>>> >>>> And everything will launch with a single seinfo value, and no other >>>> discerning input selector will match. >>> >>> Package stanzas in mac_permissions.xml are more clearly tied to a given >>> signer (and no longer supported outside of a signer stanza), and are >>> used either to assign different seinfo values to apps with the same >>> signer or to ensure that only whitelisted apps can run (if removing the >>> default stanza and explicitly enumerating all such apps). We certainly >>> do not want to lose that ability. >>> >>> The name= selector in seapp_contexts predated that support and has some >>> problems, even when you combine it with seinfo=, e.g. it is technically >>> the niceName passed by the AMS and is not necessarily the package name, >>> e.g. for shared UID apps. >>> >>> >> >> Sure. So I am thinking in reality then, leaving name in both spots at >> least gives >> is a finer granularity of control. >> >> The next things to figure out are, do we want this granularity? >> Is having name= in 2 places confusing? >> in mac_perms.xml its at least is clearly tied to the package tag > > Um, ok. Then why did you ask about removing it in one place or the other? >
I forgot about the component names. I was peering through some old demo configs I had and remembered. Personally, I have never ended up putting component names in separate domains or levels. We obviously have this ability currently though. If we move to only doing it in mac_perms.xml, we lose that ability. Is having this ability something we care about, does anyone see an intrinsic value in labeling at this granularity? -- Respectfully, William C Roberts _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
