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