From: domg472@gmail.com (Dominick Grift) Date: Mon, 02 Mar 2009 17:23:18 +0100 Subject: [refpolicy] [PATCH] add policy for Icecream In-Reply-To: <20090302163716.68641b3a@leela> References: <20090302130427.0befcb52@leela> <1235999814.19155.19.camel@notebook1.grift.internal> <20090302163716.68641b3a@leela> Message-ID: <1236010998.19155.35.camel@notebook1.grift.internal> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Mon, 2009-03-02 at 16:37 +0100, Michal Schmidt wrote: > Dne Mon, 02 Mar 2009 14:16:54 +0100 > Dominick Grift napsal: > > > Here is my take on the policy. It may or may not work but it may give > > you some ideas on how to clean it up a bit. > > Thank you for your suggestions! I'll redo the policy accordingly. > There are some bits, however, where I'd like some clarification. > It's these pieces of the diff between my and your version of > the .te file: > > > > -# the compiler node daemon > > type iceccd_t; > > type iceccd_exec_t; > > init_daemon_domain(iceccd_t, iceccd_exec_t) > > @@ -20,141 +311,182 @@ > > type iceccd_var_run_t; > > files_pid_file(iceccd_var_run_t) > > > > -# the working area > > type iceccd_cache_t; > > files_type(iceccd_cache_t) > > > > -# icecc-create-env script makes a tarball of the local compiler and > > its -# dependencies for other nodes to use > > You removed most of my comments which were meant to give the reader some idea > why the policy says what it says. Does it mean comments like these are really > not wanted? Comments are fine. If they are not too obvious. I removed them because that is my personal taste. > > type iceccd_createenv_t; > > type iceccd_createenv_exec_t; > > -domain_type(iceccd_createenv_t) > > -domain_entry_file(iceccd_createenv_t, iceccd_createenv_exec_t) > > +application_executable_file(iceccd_createenv_exec_t) > > +application_domain(iceccd_createenv_t, iceccd_createenv_exec_t) > > role system_r types iceccd_createenv_t; > > The application_* interfaces mark programs which are expected to be run by > users from interactive shells? OK, it makes sense for icecc-create-env. If user have access to the executable type and have a transition set up. > > -domain_type(iceccd_untrusted_t); > > -domain_entry_file(iceccd_untrusted_t, iceccd_cache_t) > > +application_executable_file(iceccd_cache_t); > > +application_domain(iceccd_untrusted_t, iceccd_cache_t) > > ... however, I do not think it's useful to mark the untrusted foreign compilers > as such. These should never be run by users. Alright you could also use domain_entry_type, but users wont be able to use application executables if they cannot access then or if no transition is set up. > > +dontaudit iceccd_t iceccd_untrusted_t:process { siginh rlimitinh > > +noatsecure }; > > In the original version, these three permissions were 'allow'. I don't know > exactly what they mean, I got them by observing the AVC denials during normal > operation of Icecream. If you think 'dontaudit' should be enough, I believe > you. I'll test it. Try it, These permissions usually get silently denied. > > +# use interface: iceccd_untrusted_signal() > > +allow iceccd_t iceccd_untrusted_t:process signal; > > You suggest "use interface: ..." several times. To make it absolutely clear - > are you asking me to create the named interfaces in icecream.if and use them in > icecream.te? > I thought interfaces were only useful for interaction with other policy > modules. And at the moment I can't imagine any other users of these interfaces. Interface make it easier for you to maintain policy, be it local to the module or not. I suggested the use of interfaces but its a personal taste. > > corenet_all_recvfrom_unlabeled(iceccd_t) > > corenet_all_recvfrom_netlabel(iceccd_t) > > corenet_tcp_sendrecv_generic_if(iceccd_t) > > -corenet_udp_sendrecv_generic_if(iceccd_t) > > corenet_tcp_sendrecv_generic_node(iceccd_t) > > -corenet_udp_sendrecv_generic_node(iceccd_t) > > corenet_tcp_sendrecv_all_ports(iceccd_t) > > -corenet_udp_sendrecv_all_ports(iceccd_t) > > corenet_tcp_bind_generic_node(iceccd_t) > > corenet_tcp_bind_iceccd_port(iceccd_t) > > iceccd sends UDP broadcasts to find the scheduler on the LAN. Won't removing > these rules block it? If you need them , add them. > > Michal