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 -- 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].
