Hello Stephen,
This is to update you that after loading my custom policy and making
untrusted_app as enforced (in android 4.4.4), I have noticed that process which
belongs to untrusted_app domain is not able to access (through FileInputStream)
the file having object type as - hm_phonebookaccess_data_file (even though I
have created the file as world readable)
Following is the avc denial log that I am getting - "<5>[ 581.010650]
type=1400 audit(86953.171:22): avc: denied { search } for pid=3440
comm="entprovideruser" name="com.example.contentproviderexample"
dev="mmcblk0p12" ino=114926 scontext=u:r:untrusted_app:s0
tcontext=u:object_r:hm_phonebookaccess_data_file:s0 tclass=dir"
Thanks for your support.
Regards,
Souvik
________________________________
From: William Roberts [[email protected]]
Sent: Friday, April 03, 2015 7:19 PM
To: Datta, Souvik
Cc: [email protected]; Stephen Smalley
Subject: RE: Preventing untrusted_app domain from accessing database
On Apr 3, 2015 9:46 AM, "Datta, Souvik"
<[email protected]<mailto:[email protected]>> wrote:
>
> If we consider the sceanario, that we have two apps (one rogue and another
> “good” app) running on the system that have been signed with same key and
> therefore same userId (but belonging to two different domains), would
> security policy come in the middle and prevent the rogue app from accessing
> the asset belonging to “good” app?
1. If a rogue app was signed with your private key, you lost
2. Assuming non shared uids, standard sandboxing prevents it
3. Further guarantees can be made with selinux
Note 2 and 3 are flawed if a malicious app is signed by your key. However a
scenario in which one app is attacked and shouldn't affect the other, 2 and 3
hold.
>
>
>
> From: William Roberts
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Friday, April 03, 2015 7:09 PM
> To: Datta, Souvik
> Cc: [email protected]<mailto:[email protected]>;
> Stephen Smalley
> Subject: RE: Preventing untrusted_app domain from accessing database
>
>
>
>
> On Apr 3, 2015 9:36 AM, "Datta, Souvik"
> <[email protected]<mailto:[email protected]>> wrote:
> >
> > In the beginning my aim was to prevent the untrusted_app domain from
> > accessing the database through content provider. But from the reply from
> > William Roberts, I realized that that would be possible only through
> > Android Manifest file permission.
> >
> > But if I want to prevent a rogue downloadable app (untrusted_app domain)
> > from accessing the database fifle directly, would it be possible to prevent
> > this direct access by using security context in Android 4.4.4 (with
> > setenforce as 1)
>
> Android already has sandboxing between apps. So as long as you both dont run
> in the same uid (which implies same signing key) then your fine. Also dont
> chmod the file to world read/write. If you need more guarantees then you can
> author app specific policy if you have source code control like an OEM.
>
> >
> >
> >
> >
> > -----Original Message-----
> > From: Stephen Smalley [mailto:[email protected]<mailto:[email protected]>]
> > Sent: Friday, April 03, 2015 6:51 PM
> > To: Datta, Souvik;
> > [email protected]<mailto:[email protected]>
> > Subject: Re: Preventing untrusted_app domain from accessing database
> >
> > On 04/03/2015 09:16 AM, Datta, Souvik wrote:
> > > Hello Stephen,
> > >
> > > I am using Android 4.4.4 which is distributed by a Silicon Vendor for
> > > the embedded target that I am working on. I went ahead and modified
> > > <build>/external/sepolicy/untrusted_app.te file by commenting out
> > > #permissive untrusted_app; and then did a build. But this did not have
> > > any effect. In other words, the process belonging to untrusted_app
> > > domain could still access the database
> > > (u:object_r:hm_phonebookaccess_data_file:s0)
> > >
> > > Is there any other way, this can be handled other than moving to a
> > > different version of SEAndroid?
> >
> > Are you trying to prevent direct access to the file or the ability to use
> > the ContentProvider? Two different issues. The former is enforceable by
> > SELinux at the kernel level. The latter is a matter of Android permissions
> > enforced by the middleware.
> >
> >
> > _______________________________________________
> > Seandroid-list mailing list
> > [email protected]<mailto:[email protected]>
> > To unsubscribe, send email to
> > [email protected]<mailto:[email protected]>.
> > To get help, send an email containing "help" to
> > [email protected]<mailto:[email protected]>.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
