From: stefan@seekline.net (Stefan Schulze Frielinghaus) Date: Fri, 26 Feb 2010 15:23:22 +0100 Subject: [refpolicy] services_nut.patch In-Reply-To: <4B87CF28.5010904@redhat.com> References: <4B843A67.1020406@redhat.com> <1267026787.1964.24.camel@localhost> <4B855E6B.7020308@redhat.com> <1267174822.1936.22.camel@localhost> <4B87CF28.5010904@redhat.com> Message-ID: <1267194202.9453.32.camel@localhost> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fr, 2010-02-26 at 08:39 -0500, Daniel J Walsh wrote: > On 02/26/2010 04:00 AM, Stefan Schulze Frielinghaus wrote: > > On Mi, 2010-02-24 at 12:14 -0500, Daniel J Walsh wrote: > > > >> On 02/24/2010 10:53 AM, Stefan Schulze Frielinghaus wrote: > >> > >>> On Di, 2010-02-23 at 15:28 -0500, Daniel J Walsh wrote: > >>> > >>> > >>>> http://people.fedoraproject.org/~dwalsh/SELinux/F13/services_nut.patch > >>>> > >>>> Latest nut policy. > >>>> > >>>> > >>> The following rules are unnecessary because they are already included by > >>> the interface apache_content_template as soon as the booleans > >>> httpd_enable_cgi and httpd_can_network_connect are enabled: > >>> > >>> + corenet_all_recvfrom_unlabeled(httpd_nutups_cgi_script_t) > >>> + corenet_all_recvfrom_netlabel(httpd_nutups_cgi_script_t) > >>> + corenet_tcp_sendrecv_generic_if(httpd_nutups_cgi_script_t) > >>> + corenet_tcp_sendrecv_generic_node(httpd_nutups_cgi_script_t) > >>> + corenet_tcp_sendrecv_all_ports(httpd_nutups_cgi_script_t) > >>> corenet_tcp_connect_ups_port(httpd_nutups_cgi_script_t) > >>> + corenet_udp_sendrecv_generic_if(httpd_nutups_cgi_script_t) > >>> + corenet_udp_sendrecv_generic_node(httpd_nutups_cgi_script_t) > >>> + corenet_udp_sendrecv_all_ports(httpd_nutups_cgi_script_t) > >>> + > >>> + sysnet_dns_name_resolve(httpd_nutups_cgi_script_t) > >>> > >>> > >>> > >> Ok this is a difference between apache interface in upstream and mine. > >> I removed network access > >> set by those booleans from the interface to httpd_sys_script_t > >> specific. I don't believe those interfaces should be effected by > >> booleans. I don't want my bugzilla cgi to suddenly have network access > >> just because httpd_sys_script_t needs it. > >> > > Yeah, I like this idea. > > > > > >>> Is it really necessary to include the dac_override permissions for > >>> nut_upsd_t? I thought that the upsd daemon runs as a non root user where > >>> no dac_override permissions are used. > >>> > >>> -allow nut_upsd_t self:capability { setgid setuid }; > >>> +allow nut_upsd_t self:capability { setgid setuid dac_override }; > >>> > >>> If you still have the AVC message and maybe some information of the > >>> setup, then I would like to dig a bit deeper into this because I use nut > >>> and would like to make it more secure ;-) Maybe the capabilities can > >>> even be dropped. > >>> > >>> Guess the sbin rules are not necessary for refpolicy: > >>> > >>> +corecmd_exec_sbin(nut_upsdrvctl_t) > >>> > >>> > >>> > >> Oops that is a bug. > >> > >> dac_override can come in because a file has bad ownership. > >> > > upsd runs per default as user nut on Fedora and EPEL. It should never > > run as root. > > > > > Then why does the policy have setuid/setgid? OK, I wasn't precise enough. upsd is started as root in the first place and then it drops its privileges and runs as user nut. This is even setup by the package maintainer: configure --with-user=%{name} --with-group= In the end it shouldn't hurt to allow dac_override because in most cases the daemon will/should drop its privileges right after startup. You can circumvent this by adding the option "-u root" for upsd. I was just wondering why this rules is needed. I guess the daemon was running as root in your case. I did a quick test with strace: setgid(475) = 0 setuid(57) = 0 chdir("/var/run/nut") /var/run/nut is owned by nut:nut and has mode 750. If the daemon runs as root then it would need dac_override permissions (before dropping privileges upsd only binds to two ports [IPv4/v6] and loads of course some libraries). Summarized it shouldn't hurt to allow dac_override because in the default case the daemon will drop its privileges which is recommended. I was just wondering because I haven't seen such a setup before.