how to transition a daemon to its own domain

[jiun bookworm]

Dominick,
thanks but you may have misunderstood my question,  its not the daemon that
is confined to one category
its the child processes that it spawns,   previously when in init_t  the
app could spawn processes and assign
them categories, now it  can not,  when running under myapp_t,   what makes
init_t or  other types able to
support mcs and myapp_t can not?



On Sun, Jan 19, 2014 at 10:36 PM, Dominick Grift
<dominick.grift at gmail.com>wrote:

> On Sun, 2014-01-19 at 22:29 +0300, jiun bookworm wrote:
> > ok, thanks for the help,
> >
> > i have one more question:
> >
> >
> > id like to use mcs with this  type,  how would i achieve that?,
> > before i  i was able to achieve transition, i could call a terminal
> > application  with runcon
> >
> > and it would run in the category that i specified like this:
> >
> >       '/bin/runcon/ -l s0:cX,cY   /usr/bin/appl   /path/to/inputfile
> > '
> >
> > it run in  system_u:system_r:init_t:s0:s0,cX,cY
> >
> >
> > what would i need to do to the type to make it work with categories?
> > or  even better with categories and
> >
> > something like sandbox? like this
> >      '/bin/runcon/ -t sandbox_t  -l s0:cX,cY
> >   /usr/bin/appl   /path/to/inputfile '
> >
> > though the  categories are more  important to me than the sandbox.
> >
>
> You'd probably replace the:
>
> init_daemon_domain(myapp_t, myapp_exec_t)
>
> by:
>
> init_ranged_daemon_domain(myapp_t, myapp_exec_t, s0:cX,cY)
>
> That *should* take care of the automatic range/domain transition. No
> need to change it manually
>
> >
> >
> >
> > On Sun, Jan 19, 2014 at 9:45 PM, Dominick Grift
> > <dominick.grift at gmail.com> wrote:
> >         On Sun, 2014-01-19 at 19:34 +0300, jiun bookworm wrote:
> >
> >         When you write a new policy always deal with potential
> >         transition cases
> >         first.
> >
> >         domain transitions happen on execute and file transitions
> >         happen on
> >         create
> >
> >         >
> >         > allow myapp_t self:fifo_file rw_fifo_file_perms;
> >         > allow myapp_t self:unix_stream_socket
> >         create_stream_socket_perms;
> >         > allow myapp_t self:process signal;
> >         > allow myapp_t etc_runtime_t:file { read getattr open ioctl
> >         execute};
> >
> >
> >         Above its mmapping a file with type etc_runtime_t. You should
> >         look at
> >         the raw avc denials to see which file that is and where it is,
> >         then see
> >         if its labeled appropriately. it should probably be labeled
> >         lib_t or
> >         something
> >
> >         > allow myapp_t proc_t:file { read open};
> >         > allow myapp_t bin_t:dir write;
> >
> >
> >         The above might be an access check. You should try to confirm
> >         that by
> >         using audit to record this event and then look at the syscall.
> >
> >         > allow myapp_t proc_t:file getattr;
> >         > allow myapp_t tmp_t:dir {write add_name};
> >         > allow myapp_t tmp_t:file {write open create};
> >
> >
> >         The above file should be created with a type transition to a
> >         private
> >         myapp_tmp_t files_tmp_file
> >
> >         > allow myapp_t user_home_dir_t:dir { search getattr read open
> >         write
> >         > add_name};
> >         > allow myapp_t user_home_t:file { read open  getattr ioctl
> >         create};
> >         > allow myapp_t user_home_t:dir { read open search getattr };
> >
> >
> >         The above don't quite add up. myapp is adding a directory
> >         entry and
> >         writing to some directory in /home but without a type
> >         transition rule i
> >         do not see how it can create the file with user_home_t.
> >
> >         You should analyze the raw avc denials related to the rules
> >         above to see
> >         what exactly is happening and why
> >
> >         > allow myapp_t ldconfig_exec_t:file {execute  read open
> >         > execute_no_trans};
> >
> >
> >         figure out what command exactly is executing it by looking at
> >         the raw
> >         avc denials comm="" field
> >
> >         ldconfig should usually be run as is (e.g. without a domain
> >         transition)
> >
> >         > allow myapp_t net_conf_t:file { read  open   getattr ioctl};
> >         > allow myapp_t mongod_port_t:tcp_socket name_connect;
> >         >
> >         > allow myapp_t self:tcp_socket { create setopt connect
> >         getattr getopt
> >         > write  read bind append};
> >         > allow myapp_t self:udp_socket { create connect getattr
> >         getopt setopt
> >         > write read bind append};
> >         > allow myapp_t self:netlink_route_socket { create bind
> >         getattr write
> >         > nlmsg_read nlmsg_write read setattr lock getopt setopt
> >         append };
> >         >
> >
> >
> >         The policy is pretty simple if you take care of the tmp file
> >         that is
> >         created and the mislabeled etc_runtime_t library
> >
> >         These are some of the things that i think should be in there
> >         and that
> >         might solve some issues:
> >
> >         type myapp_t;
> >         type myapp_exec_t;
> >         init_daemon_domain(myapp_t, myapp_exec_t)
> >
> >         type myapp_unit_file_t;
> >
> >         systemd_unit_file(myapp_unit_file_t)
> >
> >         type myapp_tmp_t;
> >         files_tmp_file(myapp_tmp_t)
> >
> >         manage_files_pattern(myapp_t myapp_tmp_t, myapp_tmp_t)
> >         files_tmp_filetrans(myapp_t, myapp_tmp_t, file)
> >
> >         corenet_tcp_connect_mongodb_port(myapp_t)
> >
> >         lib_exec_ldconfig(myapp_t)
> >
> >         auth_use_nsswitch(myapp_t)
> >
> >         The remainder should probably be retested, re-analyzed
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20140120/881239ee/attachment-0001.html>