disallow executing app data for the base system and add a property for third party apps

[thestinger]

It would be possible to enforce this via SELinux, by splitting up the domains.

[xifumi]

Can you elaborate?

[xifumi]

Can you elaborate?

[thestinger]

The SELinux policy currently allows executing data from app_data_file, i.e. writable app data:

priv_app.te:allow priv_app app_data_file:file rx_file_perms;
untrusted_app.te:allow untrusted_app app_data_file:file { rx_file_perms execmod };

It should be possible to outright remove this for priv_app already, but it needs testing.

For untrusted_app, the domain will need to be split up with only apps opting in to this feature being in the new domain without app_data_file execute access. It can be done for all of the base system apps though. It should already be possible. If there are some exceptions, they can be excluded.

[thestinger]

The SELinux policy currently allows executing data from app_data_file, i.e. writable app data:

priv_app.te:allow priv_app app_data_file:file rx_file_perms;
untrusted_app.te:allow untrusted_app app_data_file:file { rx_file_perms execmod };

It should be possible to outright remove this for priv_app already, but it needs testing.

For untrusted_app, the domain will need to be split up with only apps opting in to this feature being in the new domain without app_data_file execute access. It can be done for all of the base system apps though. It should already be possible. If there are some exceptions, they can be excluded.

[xifumi]

It should be possible to outright remove this for priv_app already, but it needs testing.

That might break priv-apps that engage in Classloading. Lemme dig into this a bit more and see if this can be done upstream.

[xifumi]

It should be possible to outright remove this for priv_app already, but it needs testing.

That might break priv-apps that engage in Classloading. Lemme dig into this a bit more and see if this can be done upstream.

[thestinger]

There's also #374 about dealing with class loading and perhaps other Java dynamic code execution interfaces. Those probably don't actually require executing data to run code, at least for stuff outside of apps where Android might have optimized it to an oat file.

[thestinger]

There's also #374 about dealing with class loading and perhaps other Java dynamic code execution interfaces. Those probably don't actually require executing data to run code, at least for stuff outside of apps where Android might have optimized it to an oat file.

[thestinger]

@xifumi I submitted an auditallow for the priv_app part of this: https://android-review.googlesource.com/#/c/309851/. I didn't realize that part was present until looking at the policies yesterday. I think that could just go away pretty soon.

The real project here is splitting up untrusted_app and having a system for apps to opt-in, and then ideally as a later step making that the default as a breaking change for a new API level. Once it's split up, all of the untrusted apps in the base system should be able to use the domain without app_data_file execute (which is what I meant by the base system - didn't realize priv_app had this!).

[thestinger]

@xifumi I submitted an auditallow for the priv_app part of this: https://android-review.googlesource.com/#/c/309851/. I didn't realize that part was present until looking at the policies yesterday. I think that could just go away pretty soon.

The real project here is splitting up untrusted_app and having a system for apps to opt-in, and then ideally as a later step making that the default as a breaking change for a new API level. Once it's split up, all of the untrusted apps in the base system should be able to use the domain without app_data_file execute (which is what I meant by the base system - didn't realize priv_app had this!).

[thestinger]

(of course to change the default, it would have to be upstream, but CopperheadOS could do the rest downstream)

[thestinger]

(of course to change the default, it would have to be upstream, but CopperheadOS could do the rest downstream)

[thestinger]

It ended up not being possible to do priv_app outright upstream, since Google Play uses it. CopperheadOS has gone ahead and removed it from there, but upstream would need that domain split similar to what CopperheadOS will need for untrusted_app.

[thestinger]

It ended up not being possible to do priv_app outright upstream, since Google Play uses it. CopperheadOS has gone ahead and removed it from there, but upstream would need that domain split similar to what CopperheadOS will need for untrusted_app.

[thestinger]

Replacing this issue with the more specific #530.

[thestinger]

Replacing this issue with the more specific #530.