http://people.fedoraproject.org/~dwalsh/SELinux/F13/services_nut.patch
Latest nut policy.
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)
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)
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.
> 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.
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.
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?
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.