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. >> >> >> >> > >> > > > -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
