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


For DAC, I'm able to add AID_READPROC group to the app via a new permission
in platform.xml.
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

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]


On Thu, Dec 1, 2016 at 7:24 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> On 12/01/2016 07:07 AM, ני ס wrote:
> > I have a java service app running as system. it tries to open
> > /proc/<PID>/stat file of an untrusted_app using it,
> > and I get this error:
> > *type=1400 audit(1464336899.711:510): avc: denied { search } for
> > pid=9929 comm="Binder_3" name="9886" dev="proc" ino=104925
> > scontext=u:r:system_app:s0 tcontext=u:r:untrusted_app:s0:c512,c768
> > tclass=dir permissive=0
> > *It seems that system_app lacks the permissions to view the
> > untrusted_app dir.
> > How can it be?
> > Did I miss something?
> > Note that when I connect as system (su system) I am able to read the
> > file /proc/PID/stat of the untrusted_app
>
> su system doesn't put you into the system_app domain, so it isn't
> reflective of what is allowed to a system app.
>
> The first question is why is your app trying to read /proc/PID/stat of
> an untrusted app, since that may itself reflect a security problem.
>
> I believe that the above would be denied by both the default TE policy
> (i.e. there is no allow system_app untrusted_app:dir search; rule in
> system_app.te, nor any allow system_app untrusted_app:file
> r_file_perms;), and the MLS constraints (i.e. the system app runs at s0
> while the untrusted app runs at s0:c512,c768, so the system app cannot
> read or write to the /proc/pid files of the untrusted app under the
> rules specified in the mls file; to do so, you would need to make
> system_app a mlstrustedsubject, which should be avoided if possible).
>
> Also, this would also be denied by DAC in current Android due to /proc
> being mounted with hidepid=2 unless your app also has AID_READPROC in
> its group set.  You didn't mention your Android version.
> _______________________________________________
> 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.
_______________________________________________
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.

Reply via email to