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