[refpolicy] services_nut.patch

[stefan@seekline.net (Stefan Schulze Frielinghaus)]

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.