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