All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] services_nut.patch
Date: Fri, 26 Feb 2010 08:39:52 -0500	[thread overview]
Message-ID: <4B87CF28.5010904@redhat.com> (raw)
In-Reply-To: <1267174822.1936.22.camel@localhost>

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?

  reply	other threads:[~2010-02-26 13:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-23 20:28 [refpolicy] services_nut.patch Daniel J Walsh
2010-02-24 15:53 ` Stefan Schulze Frielinghaus
2010-02-24 17:14   ` Daniel J Walsh
2010-02-26  9:00     ` Stefan Schulze Frielinghaus
2010-02-26 13:39       ` Daniel J Walsh [this message]
2010-02-26 14:23         ` Stefan Schulze Frielinghaus
  -- strict thread matches above, loose matches on Subject: below --
2010-08-26 22:02 Daniel J Walsh
2010-09-15 13:16 ` Christopher J. PeBenito
2009-11-12 21:46 Daniel J Walsh
2009-11-16 14:31 ` Stefan Schulze Frielinghaus
2009-11-16 18:32   ` Daniel J Walsh
2009-11-22 14:59     ` Stefan Schulze Frielinghaus
2009-11-23 13:05       ` Miroslav Grepl
2009-11-23 14:36         ` Stefan Schulze Frielinghaus
2009-11-23 15:19           ` Christopher J. PeBenito
2009-11-23 16:04             ` Stefan Schulze Frielinghaus
2009-11-23 16:09               ` Stefan Schulze Frielinghaus
2009-11-23 17:17                 ` Miroslav Grepl
2009-12-18 13:53                   ` Christopher J. PeBenito
2009-12-21 10:14                     ` Stefan Schulze Frielinghaus
2009-12-25 12:55                       ` Stefan Schulze Frielinghaus
2010-01-29 16:20                         ` Miroslav Grepl
2010-02-09 13:47                         ` Christopher J. PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B87CF28.5010904@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.