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? _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
