daemontools now run in their own svc_t domain.
Created attachment 21445 [details] file_contexts
Created attachment 21446 [details] type enforcement file
works with the qmail policy from the cvs repository (the one made by Russel), also tested with tcpserver based daemons and ssh. more daemons comming soon.
Created attachment 21653 [details] file contexts
Created attachment 21654 [details] type enforcement latest meanest cleanest
Created attachment 21922 [details] type enforcement
are all of your other policies dependant on this?
Committed to policy cvs. I set all of the file context lines in the following sections to match only regular files: # supervise scripts # supervise init binaries # programs that impose a given environment to daemons # helper programs # daemontools logger The practice now is to try to specify the type of the file where possible. Are these specifications ok?
Created attachment 22076 [details] macro te file macro file that defines svc_ipc_domain. this makes signal sending and fd definitions easier for policies that use daemontools.te
Created attachment 22078 [details] type enforcement svc_ipc_domain is defined as an external macro
your modifications related to the type of files are fine. pls also update the type enforcement file, because I made a few additions besides the macro stuff.
Committed. If you keep making changes, this will never make it to portage :)
Committed to portage, please check it out to make sure its ok. It doesn't have any dependancies (daemontools will optionally depend on selinux-daemontools eventually).
great, thanks for the ebuild and now, since it's in portage, I'm allowed to make changes to it, right ;) the following rules are needed in order to control the supervise scripts from a tty (I kinda use them only through a ssh connection): # Read and write the console and ttys. allow svc_script_t console_device_t:chr_file rw_file_perms; allow svc_script_t tty_device_t:chr_file rw_file_perms; allow svc_script_t ttyfile:chr_file rw_file_perms; allow svc_script_t ptyfile:chr_file rw_file_perms; allow svc_start_t console_device_t:chr_file rw_file_perms; allow svc_start_t tty_device_t:chr_file rw_file_perms; allow svc_start_t ttyfile:chr_file rw_file_perms; allow svc_start_t ptyfile:chr_file rw_file_perms; dontaudit svc_script_t sysadm_home_dir_t:dir { getattr search }; dontaudit svc_start_t sysadm_home_dir_t:dir { getattr search };
This pty/tty stuff makes me nervous. Are you sure its required? From what I've seen, daemons get along fine without it.
sys-apps/supervise-scripts is a package with a bunch of bash scripts that make life easier controlling the svc daemons. without those pty/tty stuff those scripts won't work if sysadm is logged in over the terminal, but they will work over a ssh connection. in 95% of the cases i control them over ssh, but there are cases when there is the need to control them from the console. a Happy New Year to you, peter
the deamontools.fc file point to /var/services while the default gentoo install for deamontools puts the files in /services. /var/services/.* entries therefor need to be updated to /services/.*
why does this need read/write to [pt]ty's? shouldn't the scripts just read and write from stdin and stdout? this is a security risk if the supervise scripts execute something that is malicious it will be able to read and write to other peoples terminals. Bad Bad idea...
bornsilly: /service/<daemon> should be a simlink to /var/service/<daemon> with this, you can have any number of <daemon>s in /var/sevice and add them when there is the need using supervise-scripts method: pls try this: cat << EOF > /usr/bin/svc-test #!/bin/sh echo eee EOF chmod 755 /usr/bin/svc-test chcon system_u:object_r:svc_script_exec_t /usr/bin/svc-test /usr/bin/svc-test will work over ssh, but will not work on the console if the {p,t}ty stuff is missing. funny thing is that cat << EOF > /usr/bin/svc-test echo eee EOF chmod 755 /usr/bin/svc-test chcon system_u:object_r:svc_script_exec_t /usr/bin/svc-test (without the #!/bin/sh) will work both ways without the {p,t}tty stuff. anyone knows why?
I have two thoughts on this. First, for the tty/pty stuff, this rule may be sufficient: allow { svc_script_t svc_start_t } admin_tty_type:chr_file rw_file_perms; Also, I was thinking that this might be better if it were to be run through run_init, since this does similar things as the init scripts. There would just have to be domain_auto_trans(run_init_t, svc_script_exec_t, svc_script_t). I'm not sure if this would work, but it seems like something to consider. Then it would remove the sysadm_t auto transition.
Created attachment 23605 [details] type enforcement run_init now controls svc_script_t and svc_start_t
committed to portage
as far as sys-apps/daemontools is concerned, the run_init works well. sys-apps/supervise-scripts still needs something for '/usr/bin/svc-status' in order to work with run_init. unfortunatelly, the error is masked (probably by some dontaudit rule). I will look into this once I'll get some time. one can still use run_init svstat /service/$servicename directly to get the status of a svc-controlled daemon, so it's not a major problem
