On 12/02/2016 01:59 PM, Helen Chiang wrote:
> On Fri, Dec 2, 2016 at 10:40 AM, Stephen Smalley <s...@tycho.nsa.gov
> <mailto:s...@tycho.nsa.gov>> wrote:
> You removed the offending allow rules from your domain, or the
> neverallow rules that triggered the failure? CTS has a collection of
> SELinux tests, including checking all neverallows from the AOSP policy
> for that version of Android. So you can't just remove neverallows from
> your policy to escape them. But if you removed the offending allow
> rules and your app still works, that is ok. seandroid.bitbucket.org
> <http://seandroid.bitbucket.org> has
> a list of CTS tests related to SELinux, although it may not be entirely
> up-to-date.
>
>
> I removed the offending rules from my domain
Good, that's the right thing to do (assuming your app didn't need those
permissions, of course).
> > It also needs access to files for system_app, and radio. Would still
> > need mlstrustedsubject then?
>
> What kind of access? Read or write?
> Also, you probably ought to use your own type (e.g.
> type=mydiag_app_data_file) for your data files rather than just leaving
> them in app_data_file, since that is accessible to untrusted apps
> (modulo DAC).
>
>
> Read access.
No, you shouldn't need mlstrustedsubject just for read access.
> If I use my own type, do I have to declare this somewhere
> else? Do I have to grant permission to this file type to other system
> domains, like vold, etc? In general, how do I create a new type? Sorry,
> I'm really new at this.
You need to declare the type, but you can declare it in your .te file.
The system ones are in file.te, e.g. see system_app_data_file there.
But they can go in any .te file. You'll also need to allow installd and
system_server to have the appropriate permissions to your new type;
again, see the existing rules for system_app_data_file, but you can put
your new ones in your own .te file. Note that untrusted_app is allowed
{ read write getattr } to system_app_data_file but not open, so it can
use open files passed to it over binder or local socket IPC but cannot
directly open them. You likely want the same for your new type.
> Also, what you're saying seems to imply that if I run as untrusted_app,
> I can actually access /proc/<PID>/stat of any untrusted app? This also
> means any 3rd party app can read /proc/<PID>/stat of another.
On a conventional Linux system, /proc/pid/stat is world-readable, so
apps used to be able to access any /proc/pid/stat at all. When SELinux
went enforcing for all apps in Android (5.0), we could at least limit
them to only being able to do it for other third party apps, and when
levelFrom=user was enabled (6.0), we could limit them to doing it for
other third party apps running for the same user. Then, in some version
(don't remember which one), they also starting mounting /proc with
hidepid=2, so apps cannot see other's /proc/pid at all (unless they have
AID_READPROC in their group set). Hopefully they'll eventually turn on
levelFrom=all at some point too, at which point SELinux will further
isolate all apps with unique category sets (not just per-user).
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
