Re: how to transition a daemon to its own domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



On Sun, Jan 19, 2014 at 9:45 PM, Dominick Grift <dominick.grift@xxxxxxxxx> 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



--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux