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