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. > 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. 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. > 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.
