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.
