Thanks for the reply. I'm not sure, but, there seem to be an obvious reason why a shell script is being invoked I guess. I still need to figure that out.
On Tue, Nov 19, 2013 at 5:08 PM, Stephen Smalley <[email protected]>wrote: > Any directory created by init (i.e. using built-in commands in one of > the init*.rc files) should be labeled based on file_contexts already. > But something run as a shell script doesn't use the init built-in > commands and thus will require separate action. If you are spawning > your daemon via a shell script that starts by running mkdir, then you > could either have that perform a restorecon immediately after creating > or use a seclabel stanza to run the script in a separate domain and > use a type transition for that domain. But I guess the real question > is why isn't your mkdir command directly in the init*.rc file in the > same way other mkdir commands are... > > On Tue, Nov 19, 2013 at 5:04 PM, sri linux <[email protected]> wrote: > > Ok, got it. Is there a way to lable the files/dirs that are created by > init > > belongs to my daemon? > > > > > > On Tue, Nov 19, 2013 at 4:58 PM, Stephen Smalley < > [email protected]> > > wrote: > >> > >> Your type_transition rule would only get used if the daemon domain was > >> directly creating the directory. > >> If you create the directory via a mkdir in the init*.rc file, then it > >> should be labeled by init based on file_contexts. If you are instead > >> running a shell script from init.rc and creating it there, then it > >> wouldn't get labeled (other than the default inheritance from the > >> parent directory). Looks like restorecon saw the correct context to > >> use; I assume the permission denied is just due to DAC or SELinux > >> denial to whatever uid/context your shell was in when you ran it > >> (would only work from a su shell). > >> > >> On Tue, Nov 19, 2013 at 4:54 PM, sri linux <[email protected]> wrote: > >> > 1) Yes, I was flashing all the images generated after updating policy. > >> > > >> > 2) Directory gets created by init script - NOT the daemon itself > >> > > >> > O/p of restorecon: > >> > Relabeling /data/mydaemon_xyz from u:object_r:system_data_file:s0 to > >> > u:object_r:mydaemon_xyz_data_file:s0. > >> > Could not label /data/mydaemon_xyz with > >> > u:object_r:mydaemon_xyz_data_file:s0: Permission denied > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Tue, Nov 19, 2013 at 4:38 PM, Stephen Smalley > >> > <[email protected]> > >> > wrote: > >> >> > >> >> 1) Did you reset userdata when reflashing with the new boot and > system > >> >> image that includes your policy? Otherwise, you will need to > manually > >> >> restorecon the directory to fix up its label since it already existed > >> >> prior to your policy. > >> >> > >> >> 2) Are you sure that your daemon creates the directory itself? Or is > >> >> it created by something else? > >> >> > >> >> What does restorecon -v /data/mydaemon_xyz report? > >> >> > >> >> On Tue, Nov 19, 2013 at 4:34 PM, sri linux <[email protected]> > wrote: > >> >> > Dear Stephen, Thanks for the explanation. > >> >> > > >> >> > I'm trying to define policy for my daemon, which creates some > files & > >> >> > directories in /data. I was not able to change the context for the > >> >> > directory > >> >> > that belongs to my daemon even though I have required changes in > >> >> > file_contexts & mydaemon.te files. > >> >> > > >> >> > file_contexts: > >> >> > /data/mydaemon_xyz(/.*)? u:object_r:mydaemon_xyz_data_file:s0 > >> >> > > >> >> > mydaemon.te: > >> >> > type_transition mydeamon_xyz system_data_file:{ dir file } > >> >> > mydaemon_xyz_data_file; > >> >> > > >> >> > I still see /data/mydaemon_xyz & files/dirs under it with > >> >> > system_data_file > >> >> > context instead of mydaemon_xyz context. Can someone point me what > >> >> > I'm > >> >> > missing? > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Tue, Nov 19, 2013 at 6:50 AM, Stephen Smalley > >> >> > <[email protected]> > >> >> > wrote: > >> >> >> > >> >> >> Also, this rule: > >> >> >> allow init device:chr_file { getattr ioctl }; > >> >> >> indicates that you have a /dev node that does not have a specific > >> >> >> type > >> >> >> defined in file_contexts. Rather than allowing this, you should > >> >> >> identify the device node by looking at the original avc message, > >> >> >> determine whether it should be labeled by an existing device type > or > >> >> >> a > >> >> >> new one, and define and assign that type. Then you can allow > access > >> >> >> between your daemon domain and the specific device type. > >> >> >> > >> >> >> On Tue, Nov 19, 2013 at 5:49 AM, Stephen Smalley > >> >> >> <[email protected]> wrote: > >> >> >> > You should define a separate domain for your daemon, not run it > in > >> >> >> > the > >> >> >> > init domain or change the init domain rules. Just look at one > of > >> >> >> > the > >> >> >> > existing daemon domains for an example; you need to define a > >> >> >> > domain > >> >> >> > for the process, an _exec type for its executable, declare it as > >> >> >> > an > >> >> >> > init_daemon_domain() to set up the domain transition, and assign > >> >> >> > the > >> >> >> > exec type to the executable path in the file_contexts > >> >> >> > configuration. > >> >> >> > Then rebuild your policy and regenerate your system image to > label > >> >> >> > the > >> >> >> > executable correctly. You do not need to have a separate > context > >> >> >> > for > >> >> >> > each file, but rather only for cases where you need to > distinguish > >> >> >> > access, e.g. read-only files, read-write files, etc. A context > or > >> >> >> > type is a security equivalence class. The neverallow rules in > the > >> >> >> > policy will help catch many undesirable allow rules that you > might > >> >> >> > add > >> >> >> > via audit2allow. Posting your policy for review is always a > good > >> >> >> > idea. > >> >> >> > > >> >> >> > Initial SID assignment is in the kernel code, see > >> >> >> > security/selinux/* > >> >> >> > and usage of SECINITSID_* in the code. > >> >> >> > > >> >> >> > On Mon, Nov 18, 2013 at 11:12 PM, sri linux < > [email protected]> > >> >> >> > wrote: > >> >> >> >> Hello Experts, > >> >> >> >> > >> >> >> >> I'm relatively new to SELinux/Android and trying to understand > >> >> >> >> the > >> >> >> >> how > >> >> >> >> things work. > >> >> >> >> > >> >> >> >> When I checked on the device using "ps -Z", I see that my > daemon > >> >> >> >> is > >> >> >> >> running > >> >> >> >> as part of init domain, which is in unconfined state. I tried > >> >> >> >> removing > >> >> >> >> the > >> >> >> >> unconfined statement from init policy to get the logs. > >> >> >> >> After looking at the logs, I see that, all the logs shows > "init" > >> >> >> >> as > >> >> >> >> source > >> >> >> >> context and various target contexts > (sysfs/init/system_data_file > >> >> >> >> etc). > >> >> >> >> > >> >> >> >> Now, when I try to generate the policy for the logs that I got > >> >> >> >> below > >> >> >> >> as > >> >> >> >> a > >> >> >> >> policy to be defined for init: > >> >> >> >> > >> >> >> >> allow init device:chr_file { getattr ioctl }; > >> >> >> >> allow init self:socket { read bind create write ioctl }; > >> >> >> >> > >> >> >> >> I have multiple queries: > >> >> >> >> > >> >> >> >> 1. Can I assume that, all these would be covered/defined under > >> >> >> >> AOSP > >> >> >> >> policies > >> >> >> >> as these look to be generic and might cover most of the stuff? > Or > >> >> >> >> I > >> >> >> >> still > >> >> >> >> need to define a domain for my daemon and update policy > >> >> >> >> accordingly? > >> >> >> >> > >> >> >> >> 2. Can you please help me in explaining when would I need to > >> >> >> >> define > >> >> >> >> a > >> >> >> >> separate domain if AOSP policy covers most of the things that I > >> >> >> >> need > >> >> >> >> to > >> >> >> >> take > >> >> >> >> care of for my daemon? > >> >> >> >> > >> >> >> >> 3. Do I need to have a separate context associated for each and > >> >> >> >> every > >> >> >> >> class > >> >> >> >> of file that I access? > >> >> >> >> > >> >> >> >> 4. Are there some guidelines that tells me what to do and what > >> >> >> >> NOT > >> >> >> >> to > >> >> >> >> do > >> >> >> >> from the security point of view - if I use audir2allow tool, it > >> >> >> >> generates > >> >> >> >> policy that allows what was denied. Probably I might end up in > >> >> >> >> aloowing > >> >> >> >> something, which actually should not be allowed! > >> >> >> >> > >> >> >> >> 5. How the SID be assigned to the initial tasks/objects? Where > is > >> >> >> >> this > >> >> >> >> done > >> >> >> >> exactly? > >> >> >> >> > >> >> >> >> > >> >> >> >> Thanks in advance & best regards. > >> >> >> >> > >> >> > > >> >> > > >> > > >> > > > > > >
