On 12/02/2016 01:31 PM, Helen Chiang wrote: > On Fri, Dec 2, 2016 at 10:09 AM, Stephen Smalley <s...@tycho.nsa.gov > <mailto:s...@tycho.nsa.gov>> wrote: > > On 12/02/2016 12:28 PM, Helen Chiang wrote: > > I have a similar situation. We're customizing AOSP (Marshmallow and > > Nougat) and developing a device diagnostic service that runs as "system" > > user and installed as a privileged app. The use cases of this app is to > > read /proc/<PID>/stat periodically for overall OS process information. > > Generally I would expect such functionality to go into the > system_server, as part of the AMS, or another system service. An app > could certainly present the UI for viewing that information, but > wouldn't directly need to access the /proc/pid files. > > > I can't find any APIs from AMS that will return CPU elapsed time. > SystemHealthManager is only on Nougat and the stats it returns is > dependent on battery status so it wouldn't satisfy our use case. > Ultimately, we're planning to create a new system service that will > provide the info but for our immediate needs, we have to customize the > policy files.
Yes, I would extend AMS I think. > > > > In principal, this app should be able to access everything that a > > system_app would, in addition to /proc/<PID>/stat. It also creates and > > access shared memory and unix sockets. Your previous answer implied that > > it would be insecure to make "system_app" a mlstrustedsubject. So, I > > want to create a new domain that has all the access as system_app and > > priv_app + mlstrustedsubject. Is there a way to do this without copying > > and pasting the rules directly from system_app and priv_app te files? > > Also, what allow rules are needed for shared memory and socket r/w ? > > No, you'd have to copy and modify the rules at present (if this became > common, then one would perhaps move the rules to a macro in te_macros or > elsewhere, and then call the macro from both files). However, you have > to be careful because there may be neverallow rules on system_app or > priv_app that will prevent compiling your policy if you copy certain > rules to your new domain that are supposed to be restricted to only > system_app or priv_app, and CTS also checks those neverallows. > > > I did run into and removed the offending allow rules. Are you saying > that if everything compiles with AOSP rules, CTS won't be an issue or > does CTS have additional checks? 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 has a list of CTS tests related to SELinux, although it may not be entirely up-to-date. > > 2. seapp_contexts > > > > user=system seinfo=mydiag domain=trusted_diag type=app_data_file > > levelFrom=user > > Why levelFrom=user? Does your app run per-user? If so, then it would > already run with the same category set as the user's apps and therefore > wouldn't need mlstrustedsubject. > > > 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). _______________________________________________ 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.
