hi,

I tried to do as Halen suggested, but now my java app (which run as
service) isn't starting.
in the log I have this error:
installd: invalid apk path '*/path/to/my/apk*' (bad prefix)
while I see the apk in that path.
and then I get:
ActivityManager: Process ProcessRecord{dd649ae 3859:*my.service.name
<http://my.service.name>*/1000} failed to attach

What am I doing wrong?
What I changed from the previous version is:
- adding seapp_contexts
- adding mac_permissions.xml
- adding new_domain.te

I suspect my error is with the mac_permissions.xml file.
Where do I put it? under the same folder as the rest sepolicy settings of
my app? (I have a whole stack, built of native service and native
libraries).
what exactly is its content?
this is what I have now:

<?xml version="1.0" encoding="utf-8"?>
<policy>
    <signer signature="@PLATFORM" >
        <package name="*my.service.name <http://my.service.name>*">
                <seinfo value="*my_seinfo_val*" />
        </package>
    </signer>
</policy>

Thanks!!


2016-12-02 20:40 GMT+02:00 Stephen Smalley <s...@tycho.nsa.gov>:

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

Reply via email to