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.
