In fact those entries better break if you have this patch:
commit 61846291746a3a3559f615ef3665312ccd2228c2
Author: William Roberts <[email protected]>
Date: Tue Oct 15 09:38:24 2013 -0700
tools: require that seinfo and packagename be used
Modify check_seapp.c to verify that a packagname (name)
must be specified with a signing key (seinfo). This will
help thwart spoof attacks on the packagename.
Change-Id: I8f1aa8a479cb5beb5c3522d85e3181604931ea72
On Fri, Jan 10, 2014 at 10:48 AM, William Roberts
<[email protected]> wrote:
> 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
--
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].
