On Fri, Dec 2, 2016 at 10:09 AM, Stephen Smalley <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. > > 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? > > If by shared memory you mean System V shared memory (i.e. shmget(2)), > that is not supported in Android and prohibited in policy for all > domains. If you just mean tmpfs/ashmem access, then that will get > picked up automatically via app_domain(). Creation and use of Unix > sockets is allowed to all domains in domain.te; you just need to > authorize the appropriate connections by labeling the Unix socket file > and adding unix_socket_connect() calls as appropriate. Plenty of > examples in other .te files. > > > For DAC, I'm able to add AID_READPROC group to the app via a new > > permission in platform.xml. > > Not sure that is recommended; again, you wouldn't need to do so if you > put the logic in system_server/AMS or another system service rather than > in an app. > > > For access to /proc/<PID>/stat, I created a new domain as follows: > > > > 1. mac_permissions.xml > > > > <signer signature="@PLATFORM" > > > <package name="com.mydiag.app"> > > <seinfo value="mydiag" /> > > </package> > > </signer> > > > > 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? > 3. trusted_diag.te > > > > type trusted_diag, domain, domain_deprecated; > > > > # Include all appdomain rules > > app_domain(trusted_diag) > > # Access the network. > > net_domain(trusted_diag) > > # Access bluetooth. > > bluetooth_domain(trusted_diag) > > > > # Access /proc/<PID>/stat files for metrics > > typeattribute trusted_diag mlstrustedsubject; > > r_dir_file(trusted_diag, system_app) > > r_dir_file(trusted_diag, platform_app) > > r_dir_file(trusted_diag, priv_app) > > r_dir_file(trusted_diag, untrusted_app) > > r_dir_file(trusted_diag, radio) > > > > [+ COPY LINES FROM system_app.te] > > Only copy the lines you need, and make sure your policy compiles with > all AOSP neverallows present, or you'll fail CTS. > >
_______________________________________________ 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.
