Re: Extending file_contexts

[Sava Mikalački]

Just wanted to say thank you for helping me out. You suggestions worked
with addition to granting system_server same permissions as with system_app.

Thanks again!

2016-10-18 19:08 GMT+02:00 Stephen Smalley :

> On 10/18/2016 01:01 PM, Sava Mikalački wrote:
> > And if I label it in init.rc (I have my custom one), would I need to
> > call restorecon() anyways?
>
> No, if you add a mkdir /data/system/ifw to your init.rc post-fs-data
> section, then init will create it with whatever label you specify in
> file_contexts, and then it should be fine without needing to modify
> IntentFirewall code (assuming nothing ever deletes the directory once
> created).
>
> Conceivably you could also achieve the same effect through a name-based
> type transition rule in policy, but probably not worth it:
> type_transition system_server system_data_file:dir system_data_ifw "ifw";
>
> >
> >
> > On Oct 18, 2016 18:41, "Stephen Smalley"  > > wrote:
> >
> > On 10/18/2016 12:26 PM, Stephen Smalley wrote:
> > > On 10/18/2016 11:43 AM, Sava Mikalački wrote:
> > >> Yup, exactly as Stephen said. When I set my app to share the
> > system uid,
> > >> I do get the following denial:
> > >> type=1400 audit(0.0:15): avc: denied { write } for name="ifw"
> > dev="dm-0"
> > >> ino=678613 scontext=u:r:system_app:s0
> > >> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
> > >>
> > >> Here is the output of the commands Stephen pointed out:
> > >> $ ls -lZd /data/system/ifw
> > >> drwx-- 2 system system u:object_r:system_data_file:s0 4096
> > >> 1971-01-02 12:23 /data/system/ifw
> > >>
> > >> $ ps -eZ | grep com.ariel.guardian
> > >> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
> > >> com.ariel.guardian
> > >>
> > >> So, if I create a new file type label and assign allow rule to the
> > >> system_app for this file type, would that (at least in theory)
> work?
> > >
> > > You'll need to allow access to the directory as well (your earlier
> > > policy only had an allow rule for class file; you'll need
> rw_dir_perms
> > > to the :dir as well).
> > >
> > > The other issue is getting /data/system/ifw labeled correctly.
> > Doesn't
> > > look like it is created by the init.rc file, so it won't
> automatically
> > > be labeled based on file_contexts (init does that for anything it
> > > creates).  Probably created by the IntentFirewall code, and may
> > need you
> > > to call SELinux.restorecon() on it after creating it.  You'll see
> some
> > > examples in other code, e.g.
> > >
> > frameworks/base/services/core/java/com/android/server/pm/
> PackageInstallerService.java
> > > or wallpaper/WallpaperManagerService.java.
> >
> > Yes, looks like you would need to add a SELinux.restorecon() call
> right
> > after the rulesDir.mkdirs() call in IntentFirewall().
> >
> >
>
>


-- 
I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 01:01 PM, Sava Mikalački wrote:
> And if I label it in init.rc (I have my custom one), would I need to
> call restorecon() anyways?

No, if you add a mkdir /data/system/ifw to your init.rc post-fs-data
section, then init will create it with whatever label you specify in
file_contexts, and then it should be fine without needing to modify
IntentFirewall code (assuming nothing ever deletes the directory once
created).

Conceivably you could also achieve the same effect through a name-based
type transition rule in policy, but probably not worth it:
type_transition system_server system_data_file:dir system_data_ifw "ifw";

> 
> 
> On Oct 18, 2016 18:41, "Stephen Smalley"  > wrote:
> 
> On 10/18/2016 12:26 PM, Stephen Smalley wrote:
> > On 10/18/2016 11:43 AM, Sava Mikalački wrote:
> >> Yup, exactly as Stephen said. When I set my app to share the
> system uid,
> >> I do get the following denial:
> >> type=1400 audit(0.0:15): avc: denied { write } for name="ifw"
> dev="dm-0"
> >> ino=678613 scontext=u:r:system_app:s0
> >> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
> >>
> >> Here is the output of the commands Stephen pointed out:
> >> $ ls -lZd /data/system/ifw
> >> drwx-- 2 system system u:object_r:system_data_file:s0 4096
> >> 1971-01-02 12:23 /data/system/ifw
> >>
> >> $ ps -eZ | grep com.ariel.guardian
> >> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
> >> com.ariel.guardian
> >>
> >> So, if I create a new file type label and assign allow rule to the
> >> system_app for this file type, would that (at least in theory) work?
> >
> > You'll need to allow access to the directory as well (your earlier
> > policy only had an allow rule for class file; you'll need rw_dir_perms
> > to the :dir as well).
> >
> > The other issue is getting /data/system/ifw labeled correctly. 
> Doesn't
> > look like it is created by the init.rc file, so it won't automatically
> > be labeled based on file_contexts (init does that for anything it
> > creates).  Probably created by the IntentFirewall code, and may
> need you
> > to call SELinux.restorecon() on it after creating it.  You'll see some
> > examples in other code, e.g.
> >
> 
> frameworks/base/services/core/java/com/android/server/pm/PackageInstallerService.java
> > or wallpaper/WallpaperManagerService.java.
> 
> Yes, looks like you would need to add a SELinux.restorecon() call right
> after the rulesDir.mkdirs() call in IntentFirewall().
> 
> 

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

Re: Extending file_contexts

[Sava Mikalački]

And if I label it in init.rc (I have my custom one), would I need to call
restorecon() anyways?

On Oct 18, 2016 18:41, "Stephen Smalley"  wrote:

> On 10/18/2016 12:26 PM, Stephen Smalley wrote:
> > On 10/18/2016 11:43 AM, Sava Mikalački wrote:
> >> Yup, exactly as Stephen said. When I set my app to share the system uid,
> >> I do get the following denial:
> >> type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
> >> ino=678613 scontext=u:r:system_app:s0
> >> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
> >>
> >> Here is the output of the commands Stephen pointed out:
> >> $ ls -lZd /data/system/ifw
> >> drwx-- 2 system system u:object_r:system_data_file:s0 4096
> >> 1971-01-02 12:23 /data/system/ifw
> >>
> >> $ ps -eZ | grep com.ariel.guardian
> >> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
> >> com.ariel.guardian
> >>
> >> So, if I create a new file type label and assign allow rule to the
> >> system_app for this file type, would that (at least in theory) work?
> >
> > You'll need to allow access to the directory as well (your earlier
> > policy only had an allow rule for class file; you'll need rw_dir_perms
> > to the :dir as well).
> >
> > The other issue is getting /data/system/ifw labeled correctly.  Doesn't
> > look like it is created by the init.rc file, so it won't automatically
> > be labeled based on file_contexts (init does that for anything it
> > creates).  Probably created by the IntentFirewall code, and may need you
> > to call SELinux.restorecon() on it after creating it.  You'll see some
> > examples in other code, e.g.
> > frameworks/base/services/core/java/com/android/server/pm/
> PackageInstallerService.java
> > or wallpaper/WallpaperManagerService.java.
>
> Yes, looks like you would need to add a SELinux.restorecon() call right
> after the rulesDir.mkdirs() call in IntentFirewall().
>
>
>
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 12:26 PM, Stephen Smalley wrote:
> On 10/18/2016 11:43 AM, Sava Mikalački wrote:
>> Yup, exactly as Stephen said. When I set my app to share the system uid,
>> I do get the following denial:
>> type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
>> ino=678613 scontext=u:r:system_app:s0
>> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
>>
>> Here is the output of the commands Stephen pointed out:
>> $ ls -lZd /data/system/ifw
>> drwx-- 2 system system u:object_r:system_data_file:s0 4096
>> 1971-01-02 12:23 /data/system/ifw
>>
>> $ ps -eZ | grep com.ariel.guardian
>> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
>> com.ariel.guardian
>>
>> So, if I create a new file type label and assign allow rule to the
>> system_app for this file type, would that (at least in theory) work?
> 
> You'll need to allow access to the directory as well (your earlier
> policy only had an allow rule for class file; you'll need rw_dir_perms
> to the :dir as well).
> 
> The other issue is getting /data/system/ifw labeled correctly.  Doesn't
> look like it is created by the init.rc file, so it won't automatically
> be labeled based on file_contexts (init does that for anything it
> creates).  Probably created by the IntentFirewall code, and may need you
> to call SELinux.restorecon() on it after creating it.  You'll see some
> examples in other code, e.g.
> frameworks/base/services/core/java/com/android/server/pm/PackageInstallerService.java
> or wallpaper/WallpaperManagerService.java.

Yes, looks like you would need to add a SELinux.restorecon() call right
after the rulesDir.mkdirs() call in IntentFirewall().


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

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 11:43 AM, Sava Mikalački wrote:
> Yup, exactly as Stephen said. When I set my app to share the system uid,
> I do get the following denial:
> type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
> ino=678613 scontext=u:r:system_app:s0
> tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
> 
> Here is the output of the commands Stephen pointed out:
> $ ls -lZd /data/system/ifw
> drwx-- 2 system system u:object_r:system_data_file:s0 4096
> 1971-01-02 12:23 /data/system/ifw
> 
> $ ps -eZ | grep com.ariel.guardian
> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
> com.ariel.guardian
> 
> So, if I create a new file type label and assign allow rule to the
> system_app for this file type, would that (at least in theory) work?

You'll need to allow access to the directory as well (your earlier
policy only had an allow rule for class file; you'll need rw_dir_perms
to the :dir as well).

The other issue is getting /data/system/ifw labeled correctly.  Doesn't
look like it is created by the init.rc file, so it won't automatically
be labeled based on file_contexts (init does that for anything it
creates).  Probably created by the IntentFirewall code, and may need you
to call SELinux.restorecon() on it after creating it.  You'll see some
examples in other code, e.g.
frameworks/base/services/core/java/com/android/server/pm/PackageInstallerService.java
or wallpaper/WallpaperManagerService.java.




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

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 11:43, "Sava Mikalački"  wrote:
>
> Yup, exactly as Stephen said. When I set my app to share the system uid,
I do get the following denial:
> type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
ino=678613 scontext=u:r:system_app:s0
tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
>
> Here is the output of the commands Stephen pointed out:
> $ ls -lZd /data/system/ifw
> drwx-- 2 system system u:object_r:system_data_file:s0 4096 1971-01-02
12:23 /data/system/ifw
>
> $ ps -eZ | grep com.ariel.guardian
> system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
com.ariel.guardian
>
> So, if I create a new file type label and assign allow rule to the
system_app for this file type, would that (at least in theory) work?

Yes.

>
>
> 2016-10-18 17:13 GMT+02:00 William Roberts :
>>
>> On Oct 18, 2016 11:08, "Stephen Smalley"  wrote:
>> >
>> > On 10/18/2016 10:56 AM, Stephen Smalley wrote:
>> > > On 10/18/2016 10:49 AM, Sava Mikalački wrote:
>> > >> I'm not sure how to answer the ownership question. I'm trying to
allow
>> > >> my application to write files in data/system/ifw which would be
picked
>> > >> up by the IntentFilter and then block certain application components
>> > >> from executing. I have existing code that does that and it worked on
>> > >> Marshmallow but its not working on Nougat because of that permission
>> > >> denied exception when creating a file in data/system/ifw folder.
Does
>> > >> that help out in your question?
>> > >
>> > > On a device running 7.0, ls -ld /data/system/ifw shows that it is
owned
>> > > by the system UID and is only writable by owner.  So your app has to
run
>> > > with the system UID (and thus would be system_app) in order to write
>> > > there.  I don't really think that's new to 7.0 though.
>> >
>> > What is new to 7.0 is that system_app is no longer allowed to
>> > create/write to system_data_file, which is the default type on
>> > /data/system/ifw.  So SELinux would deny those attempts (but you should
>> > get avc messages in logcat / dmesg).
>>
>> That's fantastic, I didn't notice that change. System apps have been
spewing stuff around system long enough IMO.
>>
>> >
>> > ls -lZd /data/system/ifw and ps -eZ | grep  might be
>> > interesting.
>> >
>
>
>
>
> --
> I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Sava Mikalački]

Yup, exactly as Stephen said. When I set my app to share the system uid, I
do get the following denial:
type=1400 audit(0.0:15): avc: denied { write } for name="ifw" dev="dm-0"
ino=678613 scontext=u:r:system_app:s0
tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0

Here is the output of the commands Stephen pointed out:
$ ls -lZd /data/system/ifw
drwx-- 2 system system u:object_r:system_data_file:s0 4096 1971-01-02
12:23 /data/system/ifw

$ ps -eZ | grep com.ariel.guardian
system4017  503   1588756 68980 SyS_epoll_ 768b37aa74 S
com.ariel.guardian

So, if I create a new file type label and assign allow rule to the
system_app for this file type, would that (at least in theory) work?


2016-10-18 17:13 GMT+02:00 William Roberts :

> On Oct 18, 2016 11:08, "Stephen Smalley"  wrote:
> >
> > On 10/18/2016 10:56 AM, Stephen Smalley wrote:
> > > On 10/18/2016 10:49 AM, Sava Mikalački wrote:
> > >> I'm not sure how to answer the ownership question. I'm trying to allow
> > >> my application to write files in data/system/ifw which would be picked
> > >> up by the IntentFilter and then block certain application components
> > >> from executing. I have existing code that does that and it worked on
> > >> Marshmallow but its not working on Nougat because of that permission
> > >> denied exception when creating a file in data/system/ifw folder. Does
> > >> that help out in your question?
> > >
> > > On a device running 7.0, ls -ld /data/system/ifw shows that it is owned
> > > by the system UID and is only writable by owner.  So your app has to
> run
> > > with the system UID (and thus would be system_app) in order to write
> > > there.  I don't really think that's new to 7.0 though.
> >
> > What is new to 7.0 is that system_app is no longer allowed to
> > create/write to system_data_file, which is the default type on
> > /data/system/ifw.  So SELinux would deny those attempts (but you should
> > get avc messages in logcat / dmesg).
>
> That's fantastic, I didn't notice that change. System apps have been
> spewing stuff around system long enough IMO.
>
> >
> > ls -lZd /data/system/ifw and ps -eZ | grep  might be
> > interesting.
> >
>



-- 
I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 11:08, "Stephen Smalley"  wrote:
>
> On 10/18/2016 10:56 AM, Stephen Smalley wrote:
> > On 10/18/2016 10:49 AM, Sava Mikalački wrote:
> >> I'm not sure how to answer the ownership question. I'm trying to allow
> >> my application to write files in data/system/ifw which would be picked
> >> up by the IntentFilter and then block certain application components
> >> from executing. I have existing code that does that and it worked on
> >> Marshmallow but its not working on Nougat because of that permission
> >> denied exception when creating a file in data/system/ifw folder. Does
> >> that help out in your question?
> >
> > On a device running 7.0, ls -ld /data/system/ifw shows that it is owned
> > by the system UID and is only writable by owner.  So your app has to run
> > with the system UID (and thus would be system_app) in order to write
> > there.  I don't really think that's new to 7.0 though.
>
> What is new to 7.0 is that system_app is no longer allowed to
> create/write to system_data_file, which is the default type on
> /data/system/ifw.  So SELinux would deny those attempts (but you should
> get avc messages in logcat / dmesg).

That's fantastic, I didn't notice that change. System apps have been
spewing stuff around system long enough IMO.

>
> ls -lZd /data/system/ifw and ps -eZ | grep  might be
> interesting.
>
___
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.

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 11:01, "Sava Mikalački"  wrote:
>
> Yes, this folder already exists in the system. If you place a file in a
correct XML structure, it gets picked up by a file observer in
IntentFirewall and thus enables filtering of application components. And
yes, I want to have a dynamic way of handling disabled applications. As I
said this worked on my Marshmallow build but now I have problems with
Nougat. My initial implementation of the app use systemUID but still I get
permission denied when i try to create a file.

I would imagine system app can already do that with respect to DAC and se
linux permissions. If you revert everything and run your app as a system
app, what happens?

Granted, I'm not 100% sure offhand if you should be doing this with respect
to Android compatibility concerns, but that's not my problem.

>
> 2016-10-18 16:57 GMT+02:00 William Roberts :
>>
>> On Oct 18, 2016 10:50, "Sava Mikalački"  wrote:
>> >
>> > I'm not sure how to answer the ownership question. I'm trying to allow
my application to write files in data/system/ifw
>>
>> So this already exists, is this location for intent firewall policies?
>>
>> which would be picked up by the IntentFilter and then block certain
application components from executing.
>>
>> So you want a platform app that can dynamically add/modify a policy file
for ifw?
>>
>> I have existing code that does that and it worked on Marshmallow but its
not working on Nougat because of that permission denied exception when
creating a file in data/system/ifw folder. Does that help out in your
question?
>> >
>> > 2016-10-18 16:47 GMT+02:00 Stephen Smalley :
>> >>
>> >> On 10/18/2016 10:41 AM, Sava Mikalački wrote:
>> >> > Thanks everyone for your quick answers. Yes, compilation worked
once I
>> >> > defined the type in file.te. I will try this out and also will try
with
>> >> > system_app, probably thats simpler as you said. Whats confusing me
is
>> >> > that I get Permission denied exception when I try to create a file
in
>> >> > that directory with a system app but there is no selinux avc denial
>> >> > before the exception, it just fires the exception and thats it, so
I'm
>> >> > afraid if changing the sepolicy would even work.
>> >>
>> >> What's the ownership and mode of the directory?
>> >>
>> >> >
>> >> > 2016-10-18 16:35 GMT+02:00 Stephen Smalley > >> > >:
>> >> >
>> >> > On 10/18/2016 10:23 AM, William Roberts wrote:
>> >> > > On Oct 18, 2016 9:34 AM, "Sava Mikalački" <
mikalac...@gmail.com 
>> >> > > >>
wrote:
>> >> > >>
>> >> > >> I'm trying to extend aosp file_contexts by adding a new
entry for
>> >> > > /data/system/ifw. I've created a file_contexts under my
vendor directory
>> >> > > structure but if I try to use the new label, build crashes
with unknown
>> >> > > type. I'm
>> >> > >
>> >> > > You need to declare the type with the type keyword:
>> >> > >
>> >> > > type system_data_ifw, file_type;
>> >> > >
>> >> > > trying to enable a platform_app to write to data/system/ifw
and here is
>> >> > > what I have so far:
>> >> > >> file_contexts:
>> >> > >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
>> >> > >> platform_app.te:
>> >> > >> allow platform_app system_data_ifw:file create_file_perms;
>> >> > >
>> >> > > Platform applications shouldn't be creating stuff around the
system,
>> >> > > they should stick to their sandbox. I cant recall offhand,
but a never
>> >> > > allow I wrote might assert itself on that allow rule.
>> >> >
>> >> > Probably not since it is a new type he just defined.  However,
it occurs
>> >> > to me that DAC will be a problem for this use case, since
platform apps
>> >> > can be assigned arbitrary UIDs and thus won't be able to pass
the DAC
>> >> > checks on writing to /data/system/ifw unless you set up a
group, map a
>> >> > permission to that group, assign that group to
/data/system/ifw, and
>> >> > make it group-writable.  Simpler if you use a system_app or
some other
>> >> > fixed UID app instead, although that carries its own set of
issues.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > I have only two questions: How much and give it to me.
>> >>
>> >
>> >
>> >
>> > --
>> > I have only two questions: How much and give it to me.
>
>
>
>
> --
> I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 10:56 AM, Stephen Smalley wrote:
> On 10/18/2016 10:49 AM, Sava Mikalački wrote:
>> I'm not sure how to answer the ownership question. I'm trying to allow
>> my application to write files in data/system/ifw which would be picked
>> up by the IntentFilter and then block certain application components
>> from executing. I have existing code that does that and it worked on
>> Marshmallow but its not working on Nougat because of that permission
>> denied exception when creating a file in data/system/ifw folder. Does
>> that help out in your question?
> 
> On a device running 7.0, ls -ld /data/system/ifw shows that it is owned
> by the system UID and is only writable by owner.  So your app has to run
> with the system UID (and thus would be system_app) in order to write
> there.  I don't really think that's new to 7.0 though.

What is new to 7.0 is that system_app is no longer allowed to
create/write to system_data_file, which is the default type on
/data/system/ifw.  So SELinux would deny those attempts (but you should
get avc messages in logcat / dmesg).

ls -lZd /data/system/ifw and ps -eZ | grep  might be
interesting.

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

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 10:50, "Sava Mikalački"  wrote:
>
> I'm not sure how to answer the ownership question. I'm trying to allow my
application to write files in data/system/ifw

So this already exists, is this location for intent firewall policies?

which would be picked up by the IntentFilter and then block certain
application components from executing.

So you want a platform app that can dynamically add/modify a policy file
for ifw?

I have existing code that does that and it worked on Marshmallow but its
not working on Nougat because of that permission denied exception when
creating a file in data/system/ifw folder. Does that help out in your
question?
>
> 2016-10-18 16:47 GMT+02:00 Stephen Smalley :
>>
>> On 10/18/2016 10:41 AM, Sava Mikalački wrote:
>> > Thanks everyone for your quick answers. Yes, compilation worked once I
>> > defined the type in file.te. I will try this out and also will try with
>> > system_app, probably thats simpler as you said. Whats confusing me is
>> > that I get Permission denied exception when I try to create a file in
>> > that directory with a system app but there is no selinux avc denial
>> > before the exception, it just fires the exception and thats it, so I'm
>> > afraid if changing the sepolicy would even work.
>>
>> What's the ownership and mode of the directory?
>>
>> >
>> > 2016-10-18 16:35 GMT+02:00 Stephen Smalley > > >:
>> >
>> > On 10/18/2016 10:23 AM, William Roberts wrote:
>> > > On Oct 18, 2016 9:34 AM, "Sava Mikalački" mailto:mikalac...@gmail.com>
>> > > >>
wrote:
>> > >>
>> > >> I'm trying to extend aosp file_contexts by adding a new entry
for
>> > > /data/system/ifw. I've created a file_contexts under my vendor
directory
>> > > structure but if I try to use the new label, build crashes with
unknown
>> > > type. I'm
>> > >
>> > > You need to declare the type with the type keyword:
>> > >
>> > > type system_data_ifw, file_type;
>> > >
>> > > trying to enable a platform_app to write to data/system/ifw and
here is
>> > > what I have so far:
>> > >> file_contexts:
>> > >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
>> > >> platform_app.te:
>> > >> allow platform_app system_data_ifw:file create_file_perms;
>> > >
>> > > Platform applications shouldn't be creating stuff around the
system,
>> > > they should stick to their sandbox. I cant recall offhand, but a
never
>> > > allow I wrote might assert itself on that allow rule.
>> >
>> > Probably not since it is a new type he just defined.  However, it
occurs
>> > to me that DAC will be a problem for this use case, since platform
apps
>> > can be assigned arbitrary UIDs and thus won't be able to pass the
DAC
>> > checks on writing to /data/system/ifw unless you set up a group,
map a
>> > permission to that group, assign that group to /data/system/ifw,
and
>> > make it group-writable.  Simpler if you use a system_app or some
other
>> > fixed UID app instead, although that carries its own set of issues.
>> >
>> >
>> >
>> >
>> >
>> > --
>> > I have only two questions: How much and give it to me.
>>
>
>
>
> --
> I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Sava Mikalački]

Yes, this folder already exists in the system. If you place a file in a
correct XML structure, it gets picked up by a file observer in
IntentFirewall and thus enables filtering of application components. And
yes, I want to have a dynamic way of handling disabled applications. As I
said this worked on my Marshmallow build but now I have problems with
Nougat. My initial implementation of the app use systemUID but still I get
permission denied when i try to create a file.

2016-10-18 16:57 GMT+02:00 William Roberts :

> On Oct 18, 2016 10:50, "Sava Mikalački"  wrote:
> >
> > I'm not sure how to answer the ownership question. I'm trying to allow
> my application to write files in data/system/ifw
>
> So this already exists, is this location for intent firewall policies?
>
> which would be picked up by the IntentFilter and then block certain
> application components from executing.
>
> So you want a platform app that can dynamically add/modify a policy file
> for ifw?
>
> I have existing code that does that and it worked on Marshmallow but its
> not working on Nougat because of that permission denied exception when
> creating a file in data/system/ifw folder. Does that help out in your
> question?
> >
> > 2016-10-18 16:47 GMT+02:00 Stephen Smalley :
> >>
> >> On 10/18/2016 10:41 AM, Sava Mikalački wrote:
> >> > Thanks everyone for your quick answers. Yes, compilation worked once I
> >> > defined the type in file.te. I will try this out and also will try
> with
> >> > system_app, probably thats simpler as you said. Whats confusing me is
> >> > that I get Permission denied exception when I try to create a file in
> >> > that directory with a system app but there is no selinux avc denial
> >> > before the exception, it just fires the exception and thats it, so I'm
> >> > afraid if changing the sepolicy would even work.
> >>
> >> What's the ownership and mode of the directory?
> >>
> >> >
> >> > 2016-10-18 16:35 GMT+02:00 Stephen Smalley  >> > >:
> >> >
> >> > On 10/18/2016 10:23 AM, William Roberts wrote:
> >> > > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  
> >> > > >>
> wrote:
> >> > >>
> >> > >> I'm trying to extend aosp file_contexts by adding a new entry
> for
> >> > > /data/system/ifw. I've created a file_contexts under my vendor
> directory
> >> > > structure but if I try to use the new label, build crashes with
> unknown
> >> > > type. I'm
> >> > >
> >> > > You need to declare the type with the type keyword:
> >> > >
> >> > > type system_data_ifw, file_type;
> >> > >
> >> > > trying to enable a platform_app to write to data/system/ifw and
> here is
> >> > > what I have so far:
> >> > >> file_contexts:
> >> > >> /data/system/ifw(/.*)?
>  u:object_r:system_data_ifw:s0
> >> > >> platform_app.te:
> >> > >> allow platform_app system_data_ifw:file create_file_perms;
> >> > >
> >> > > Platform applications shouldn't be creating stuff around the
> system,
> >> > > they should stick to their sandbox. I cant recall offhand, but
> a never
> >> > > allow I wrote might assert itself on that allow rule.
> >> >
> >> > Probably not since it is a new type he just defined.  However, it
> occurs
> >> > to me that DAC will be a problem for this use case, since
> platform apps
> >> > can be assigned arbitrary UIDs and thus won't be able to pass the
> DAC
> >> > checks on writing to /data/system/ifw unless you set up a group,
> map a
> >> > permission to that group, assign that group to /data/system/ifw,
> and
> >> > make it group-writable.  Simpler if you use a system_app or some
> other
> >> > fixed UID app instead, although that carries its own set of
> issues.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > I have only two questions: How much and give it to me.
> >>
> >
> >
> >
> > --
> > I have only two questions: How much and give it to me.
>



-- 
I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 10:49 AM, Sava Mikalački wrote:
> I'm not sure how to answer the ownership question. I'm trying to allow
> my application to write files in data/system/ifw which would be picked
> up by the IntentFilter and then block certain application components
> from executing. I have existing code that does that and it worked on
> Marshmallow but its not working on Nougat because of that permission
> denied exception when creating a file in data/system/ifw folder. Does
> that help out in your question?

On a device running 7.0, ls -ld /data/system/ifw shows that it is owned
by the system UID and is only writable by owner.  So your app has to run
with the system UID (and thus would be system_app) in order to write
there.  I don't really think that's new to 7.0 though.

> 
> 2016-10-18 16:47 GMT+02:00 Stephen Smalley  >:
> 
> On 10/18/2016 10:41 AM, Sava Mikalački wrote:
> > Thanks everyone for your quick answers. Yes, compilation worked once I
> > defined the type in file.te. I will try this out and also will try with
> > system_app, probably thats simpler as you said. Whats confusing me is
> > that I get Permission denied exception when I try to create a file in
> > that directory with a system app but there is no selinux avc denial
> > before the exception, it just fires the exception and thats it, so I'm
> > afraid if changing the sepolicy would even work.
> 
> What's the ownership and mode of the directory?
> 
> >
> > 2016-10-18 16:35 GMT+02:00 Stephen Smalley  
> > >>:
> >
> > On 10/18/2016 10:23 AM, William Roberts wrote:
> > > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  
> >
> > > 
>  > >>
> > >> I'm trying to extend aosp file_contexts by adding a new
> entry for
> > > /data/system/ifw. I've created a file_contexts under my
> vendor directory
> > > structure but if I try to use the new label, build crashes
> with unknown
> > > type. I'm
> > >
> > > You need to declare the type with the type keyword:
> > >
> > > type system_data_ifw, file_type;
> > >
> > > trying to enable a platform_app to write to data/system/ifw
> and here is
> > > what I have so far:
> > >> file_contexts:
> > >> /data/system/ifw(/.*)? 
>  u:object_r:system_data_ifw:s0
> > >> platform_app.te:
> > >> allow platform_app system_data_ifw:file create_file_perms;
> > >
> > > Platform applications shouldn't be creating stuff around the
> system,
> > > they should stick to their sandbox. I cant recall offhand,
> but a never
> > > allow I wrote might assert itself on that allow rule.
> >
> > Probably not since it is a new type he just defined.  However,
> it occurs
> > to me that DAC will be a problem for this use case, since
> platform apps
> > can be assigned arbitrary UIDs and thus won't be able to pass
> the DAC
> > checks on writing to /data/system/ifw unless you set up a
> group, map a
> > permission to that group, assign that group to
> /data/system/ifw, and
> > make it group-writable.  Simpler if you use a system_app or
> some other
> > fixed UID app instead, although that carries its own set of
> issues.
> >
> >
> >
> >
> >
> > --
> > I have only two questions: How much and give it to me.
> 
> 
> 
> 
> -- 
> I have only two questions: How much and give it to me.

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

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 10:51, "Stephen Smalley"  wrote:
>
> On 10/18/2016 10:23 AM, William Roberts wrote:
> > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  > > wrote:
> >>
> >> I'm trying to extend aosp file_contexts by adding a new entry for
> > /data/system/ifw. I've created a file_contexts under my vendor directory
> > structure but if I try to use the new label, build crashes with unknown
> > type. I'm
> >
> > You need to declare the type with the type keyword:
> >
> > type system_data_ifw, file_type;
>
> Just to be clear, you also want at least the data_file_type attribute
> here (for all types on files under /data) and possibly the
> mlstrustedobject attribute (if it needs to be writable by any app using
> levelFrom= in seapp_contexts).  The latter is not necessary for
system_app.

Correct, typing from phone is too hard for underscores.
>
> >
> > trying to enable a platform_app to write to data/system/ifw and here is
> > what I have so far:
> >> file_contexts:
> >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
> >> platform_app.te:
> >> allow platform_app system_data_ifw:file create_file_perms;
> >
> > Platform applications shouldn't be creating stuff around the system,
> > they should stick to their sandbox. I cant recall offhand, but a never
> > allow I wrote might assert itself on that allow rule.
> >
> >>
> >> I also tried adding:
> >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
> >> to my device specific sepolicy but it still doesnt get picked up.
> >>
> >> Am I taking the right approach?
> >
> > You extend policy in your own specific location set by
> > BOARD_SEPOlICY_DIRS = path/to/directory
> >
> > Then just add files to that directory. No need to ever touch
> > system/sepolicy or on older versions of Android external/sepolicy.
> >
> >>
> >> --
> >> I have only two questions: How much and give it to me.
> >>
> >> ___
> >> 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.
> >
>
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 10:23 AM, William Roberts wrote:
> On Oct 18, 2016 9:34 AM, "Sava Mikalački"  > wrote:
>>
>> I'm trying to extend aosp file_contexts by adding a new entry for
> /data/system/ifw. I've created a file_contexts under my vendor directory
> structure but if I try to use the new label, build crashes with unknown
> type. I'm
> 
> You need to declare the type with the type keyword:
> 
> type system_data_ifw, file_type;

Just to be clear, you also want at least the data_file_type attribute
here (for all types on files under /data) and possibly the
mlstrustedobject attribute (if it needs to be writable by any app using
levelFrom= in seapp_contexts).  The latter is not necessary for system_app.

> 
> trying to enable a platform_app to write to data/system/ifw and here is
> what I have so far:
>> file_contexts:
>> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
>> platform_app.te:
>> allow platform_app system_data_ifw:file create_file_perms;
> 
> Platform applications shouldn't be creating stuff around the system,
> they should stick to their sandbox. I cant recall offhand, but a never
> allow I wrote might assert itself on that allow rule.
> 
>>
>> I also tried adding:
>> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
>> to my device specific sepolicy but it still doesnt get picked up.
>>
>> Am I taking the right approach? 
> 
> You extend policy in your own specific location set by
> BOARD_SEPOlICY_DIRS = path/to/directory
> 
> Then just add files to that directory. No need to ever touch
> system/sepolicy or on older versions of Android external/sepolicy.
> 
>>
>> --
>> I have only two questions: How much and give it to me.
>>
>> ___
>> 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.
> 

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

Re: Extending file_contexts

[Sava Mikalački]

I'm not sure how to answer the ownership question. I'm trying to allow my
application to write files in data/system/ifw which would be picked up by
the IntentFilter and then block certain application components from
executing. I have existing code that does that and it worked on Marshmallow
but its not working on Nougat because of that permission denied exception
when creating a file in data/system/ifw folder. Does that help out in your
question?

2016-10-18 16:47 GMT+02:00 Stephen Smalley :

> On 10/18/2016 10:41 AM, Sava Mikalački wrote:
> > Thanks everyone for your quick answers. Yes, compilation worked once I
> > defined the type in file.te. I will try this out and also will try with
> > system_app, probably thats simpler as you said. Whats confusing me is
> > that I get Permission denied exception when I try to create a file in
> > that directory with a system app but there is no selinux avc denial
> > before the exception, it just fires the exception and thats it, so I'm
> > afraid if changing the sepolicy would even work.
>
> What's the ownership and mode of the directory?
>
> >
> > 2016-10-18 16:35 GMT+02:00 Stephen Smalley  > >:
> >
> > On 10/18/2016 10:23 AM, William Roberts wrote:
> > > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  
> > > >>
> wrote:
> > >>
> > >> I'm trying to extend aosp file_contexts by adding a new entry for
> > > /data/system/ifw. I've created a file_contexts under my vendor
> directory
> > > structure but if I try to use the new label, build crashes with
> unknown
> > > type. I'm
> > >
> > > You need to declare the type with the type keyword:
> > >
> > > type system_data_ifw, file_type;
> > >
> > > trying to enable a platform_app to write to data/system/ifw and
> here is
> > > what I have so far:
> > >> file_contexts:
> > >> /data/system/ifw(/.*)?
>  u:object_r:system_data_ifw:s0
> > >> platform_app.te:
> > >> allow platform_app system_data_ifw:file create_file_perms;
> > >
> > > Platform applications shouldn't be creating stuff around the
> system,
> > > they should stick to their sandbox. I cant recall offhand, but a
> never
> > > allow I wrote might assert itself on that allow rule.
> >
> > Probably not since it is a new type he just defined.  However, it
> occurs
> > to me that DAC will be a problem for this use case, since platform
> apps
> > can be assigned arbitrary UIDs and thus won't be able to pass the DAC
> > checks on writing to /data/system/ifw unless you set up a group, map
> a
> > permission to that group, assign that group to /data/system/ifw, and
> > make it group-writable.  Simpler if you use a system_app or some
> other
> > fixed UID app instead, although that carries its own set of issues.
> >
> >
> >
> >
> >
> > --
> > I have only two questions: How much and give it to me.
>
>


-- 
I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 10:41 AM, Sava Mikalački wrote:
> Thanks everyone for your quick answers. Yes, compilation worked once I
> defined the type in file.te. I will try this out and also will try with
> system_app, probably thats simpler as you said. Whats confusing me is
> that I get Permission denied exception when I try to create a file in
> that directory with a system app but there is no selinux avc denial
> before the exception, it just fires the exception and thats it, so I'm
> afraid if changing the sepolicy would even work.

What's the ownership and mode of the directory?

> 
> 2016-10-18 16:35 GMT+02:00 Stephen Smalley  >:
> 
> On 10/18/2016 10:23 AM, William Roberts wrote:
> > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  
> > >> wrote:
> >>
> >> I'm trying to extend aosp file_contexts by adding a new entry for
> > /data/system/ifw. I've created a file_contexts under my vendor directory
> > structure but if I try to use the new label, build crashes with unknown
> > type. I'm
> >
> > You need to declare the type with the type keyword:
> >
> > type system_data_ifw, file_type;
> >
> > trying to enable a platform_app to write to data/system/ifw and here is
> > what I have so far:
> >> file_contexts:
> >> /data/system/ifw(/.*)?   
> u:object_r:system_data_ifw:s0
> >> platform_app.te:
> >> allow platform_app system_data_ifw:file create_file_perms;
> >
> > Platform applications shouldn't be creating stuff around the system,
> > they should stick to their sandbox. I cant recall offhand, but a never
> > allow I wrote might assert itself on that allow rule.
> 
> Probably not since it is a new type he just defined.  However, it occurs
> to me that DAC will be a problem for this use case, since platform apps
> can be assigned arbitrary UIDs and thus won't be able to pass the DAC
> checks on writing to /data/system/ifw unless you set up a group, map a
> permission to that group, assign that group to /data/system/ifw, and
> make it group-writable.  Simpler if you use a system_app or some other
> fixed UID app instead, although that carries its own set of issues.
> 
> 
> 
> 
> 
> -- 
> I have only two questions: How much and give it to me.

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

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 10:41 AM, "Sava Mikalački"  wrote:
>
> Thanks everyone for your quick answers. Yes, compilation worked once I
defined the type in file.te. I will try this out and also will try with
system_app, probably thats simpler as you said. Whats confusing me is that
I get Permission denied exception when I try to create a file in that
directory with a system app but there is no selinux avc denial before the
exception, it just fires the exception and thats it, so I'm afraid if
changing the sepolicy would even work.

That's the DAC issues Stephen pointed out

>
> 2016-10-18 16:35 GMT+02:00 Stephen Smalley :
>>
>> On 10/18/2016 10:23 AM, William Roberts wrote:
>> > On Oct 18, 2016 9:34 AM, "Sava Mikalački" > > > wrote:
>> >>
>> >> I'm trying to extend aosp file_contexts by adding a new entry for
>> > /data/system/ifw. I've created a file_contexts under my vendor
directory
>> > structure but if I try to use the new label, build crashes with unknown
>> > type. I'm
>> >
>> > You need to declare the type with the type keyword:
>> >
>> > type system_data_ifw, file_type;
>> >
>> > trying to enable a platform_app to write to data/system/ifw and here is
>> > what I have so far:
>> >> file_contexts:
>> >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
>> >> platform_app.te:
>> >> allow platform_app system_data_ifw:file create_file_perms;
>> >
>> > Platform applications shouldn't be creating stuff around the system,
>> > they should stick to their sandbox. I cant recall offhand, but a never
>> > allow I wrote might assert itself on that allow rule.
>>
>> Probably not since it is a new type he just defined.  However, it occurs
>> to me that DAC will be a problem for this use case, since platform apps
>> can be assigned arbitrary UIDs and thus won't be able to pass the DAC
>> checks on writing to /data/system/ifw unless you set up a group, map a
>> permission to that group, assign that group to /data/system/ifw, and
>> make it group-writable.  Simpler if you use a system_app or some other
>> fixed UID app instead, although that carries its own set of issues.
>>
>>
>
>
>
> --
> I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[Sava Mikalački]

Thanks everyone for your quick answers. Yes, compilation worked once I
defined the type in file.te. I will try this out and also will try with
system_app, probably thats simpler as you said. Whats confusing me is that
I get Permission denied exception when I try to create a file in that
directory with a system app but there is no selinux avc denial before the
exception, it just fires the exception and thats it, so I'm afraid if
changing the sepolicy would even work.

2016-10-18 16:35 GMT+02:00 Stephen Smalley :

> On 10/18/2016 10:23 AM, William Roberts wrote:
> > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  > > wrote:
> >>
> >> I'm trying to extend aosp file_contexts by adding a new entry for
> > /data/system/ifw. I've created a file_contexts under my vendor directory
> > structure but if I try to use the new label, build crashes with unknown
> > type. I'm
> >
> > You need to declare the type with the type keyword:
> >
> > type system_data_ifw, file_type;
> >
> > trying to enable a platform_app to write to data/system/ifw and here is
> > what I have so far:
> >> file_contexts:
> >> /data/system/ifw(/.*)?
>  u:object_r:system_data_ifw:s0
> >> platform_app.te:
> >> allow platform_app system_data_ifw:file create_file_perms;
> >
> > Platform applications shouldn't be creating stuff around the system,
> > they should stick to their sandbox. I cant recall offhand, but a never
> > allow I wrote might assert itself on that allow rule.
>
> Probably not since it is a new type he just defined.  However, it occurs
> to me that DAC will be a problem for this use case, since platform apps
> can be assigned arbitrary UIDs and thus won't be able to pass the DAC
> checks on writing to /data/system/ifw unless you set up a group, map a
> permission to that group, assign that group to /data/system/ifw, and
> make it group-writable.  Simpler if you use a system_app or some other
> fixed UID app instead, although that carries its own set of issues.
>
>
>


-- 
I have only two questions: How much and give it to me.
___
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.

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 10:33 AM, "Stephen Smalley"  wrote:
>
> On 10/18/2016 10:23 AM, William Roberts wrote:
> > On Oct 18, 2016 9:34 AM, "Sava Mikalački"  > > wrote:
> >>
> >> I'm trying to extend aosp file_contexts by adding a new entry for
> > /data/system/ifw. I've created a file_contexts under my vendor directory
> > structure but if I try to use the new label, build crashes with unknown
> > type. I'm
> >
> > You need to declare the type with the type keyword:
> >
> > type system_data_ifw, file_type;
> >
> > trying to enable a platform_app to write to data/system/ifw and here is
> > what I have so far:
> >> file_contexts:
> >> /data/system/ifw(/.*)?
 u:object_r:system_data_ifw:s0
> >> platform_app.te:
> >> allow platform_app system_data_ifw:file create_file_perms;
> >
> > Platform applications shouldn't be creating stuff around the system,
> > they should stick to their sandbox. I cant recall offhand, but a never
> > allow I wrote might assert itself on that allow rule.
>
> Probably not since it is a new type he just defined.

One could say don't allow platform apps to create things outside of their
sandbox type. I looked at my rule, it was only for untrusted app though.

However, it occurs
> to me that DAC will be a problem for this use case, since platform apps
> can be assigned arbitrary UIDs and thus won't be able to pass the DAC
> checks on writing to /data/system/ifw unless you set up a group, map a
> permission to that group, assign that group to /data/system/ifw, and
> make it group-writable.  Simpler if you use a system_app or some other
> fixed UID app instead, although that carries its own set of issues.

Yeah, bit we a know that chown 777 is the way to fix that;-p. Don't do
that, platform apps are no designed to be creating resources out the
application sandbox. If you need to create and share data, you can use a
host of mechanisms available on Android. Unix sockets and binder are
readily available. This way your platform app can selectively share it's
isolated data sandbox directory contents via passed fd as an example.
___
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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 10:23 AM, William Roberts wrote:
> On Oct 18, 2016 9:34 AM, "Sava Mikalački"  > wrote:
>>
>> I'm trying to extend aosp file_contexts by adding a new entry for
> /data/system/ifw. I've created a file_contexts under my vendor directory
> structure but if I try to use the new label, build crashes with unknown
> type. I'm
> 
> You need to declare the type with the type keyword:
> 
> type system_data_ifw, file_type;
> 
> trying to enable a platform_app to write to data/system/ifw and here is
> what I have so far:
>> file_contexts:
>> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
>> platform_app.te:
>> allow platform_app system_data_ifw:file create_file_perms;
> 
> Platform applications shouldn't be creating stuff around the system,
> they should stick to their sandbox. I cant recall offhand, but a never
> allow I wrote might assert itself on that allow rule.

Probably not since it is a new type he just defined.  However, it occurs
to me that DAC will be a problem for this use case, since platform apps
can be assigned arbitrary UIDs and thus won't be able to pass the DAC
checks on writing to /data/system/ifw unless you set up a group, map a
permission to that group, assign that group to /data/system/ifw, and
make it group-writable.  Simpler if you use a system_app or some other
fixed UID app instead, although that carries its own set of issues.


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

Re: Extending file_contexts

[William Roberts]

On Oct 18, 2016 9:34 AM, "Sava Mikalački"  wrote:
>
> I'm trying to extend aosp file_contexts by adding a new entry for
/data/system/ifw. I've created a file_contexts under my vendor directory
structure but if I try to use the new label, build crashes with unknown
type. I'm

You need to declare the type with the type keyword:

type system_data_ifw, file_type;

trying to enable a platform_app to write to data/system/ifw and here is
what I have so far:
> file_contexts:
> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
> platform_app.te:
> allow platform_app system_data_ifw:file create_file_perms;

Platform applications shouldn't be creating stuff around the system, they
should stick to their sandbox. I cant recall offhand, but a never allow I
wrote might assert itself on that allow rule.

>
> I also tried adding:
> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
> to my device specific sepolicy but it still doesnt get picked up.
>
> Am I taking the right approach?

You extend policy in your own specific location set by BOARD_SEPOlICY_DIRS
= path/to/directory

Then just add files to that directory. No need to ever touch
system/sepolicy or on older versions of Android external/sepolicy.

>
> --
> I have only two questions: How much and give it to me.
>
> ___
> 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.

Re: Extending file_contexts

[Stephen Smalley]

On 10/18/2016 09:33 AM, Sava Mikalački wrote:
> I'm trying to extend aosp file_contexts by adding a new entry for
> /data/system/ifw. I've created a file_contexts under my vendor directory
> structure but if I try to use the new label, build crashes with unknown
> type. I'm trying to enable a platform_app to write to data/system/ifw
> and here is what I have so far:
> file_contexts:
> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
> platform_app.te:
> allow platform_app system_data_ifw:file create_file_perms;
> 
> I also tried adding:
> /data/system/ifw(/.*)?   u:object_r:system_data_ifw:s0
> to my device specific sepolicy but it still doesnt get picked up.
> 
> Am I taking the right approach? 

You need to also define the type in a .te file, e.g.
$ cat file.te
type system_data_ifw, file_type, data_file_type, mlstrustedobject;

And add a BOARD_SEPOLICY_DIRS definition to your BoardConfig.mk file.

Look at the AOSP device policies for examples.



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