Re: Subgit SELinux issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/02/2015 04:26 AM, Matthew Saltzman wrote:
> On Wed, 2015-09-30 at 10:34 +0200, Miroslav Grepl wrote:
>> On 09/28/2015 05:48 PM, Matthew Saltzman wrote:
>>> On Wed, 2015-09-23 at 09:13 +0200, Miroslav Grepl wrote:
>>>> On 09/22/2015 08:37 PM, Matthew Saltzman wrote:
>>>>> On Tue, 2015-09-22 at 19:21 +0100, Trevor Hemsley wrote:
>>>>>> On 22/09/15 18:50, Matthew Saltzman wrote:
>>>>>>>     for pid file '/var/www/svn/FlopC++/subgit/daemon.pid
>>>>>>
>>>>>> Probably not the best location for a pid file. I'd suspect
>>>>>> that
>>>>>> write
>>>>>> access to anything under /var/www is disallowed. Can you not
>>>>>> move
>>>>>> it
>>>>>> to
>>>>>> /var/run?
>>>>>
>>>>> *I* can't. It's hard-coded in a compiled executable. I could
>>>>> make
>>>>> that
>>>>> recommendation to the Subgit folks. I suspect they may do that
>>>>> because
>>>>> they know for sure where the directory they are executing from
>>>>> is,
>>>>> but
>>>>> they may not feel they have a guarantee that /var/run is
>>>>> available
>>>>> in
>>>>> every *nix distribution.
>>>>
>>>> We can label /var/www/svn/FlopC++/subgit for example if it is
>>>> owned
>>>> by a
>>>> package.
>>>>
>>>> The main gole is we need to get AVCs. Try to re-test it and run
>>>>
>>>> #ausearch -m avc,user_avc -ts recent
>>>>
>>>>>
>>>>> On the other hand, the Subversion repositories themselves are
>>>>> in
>>>>> /var/www/svn and interacting with them works fine (including
>>>>> writes),
>>>>> modulo this issue.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Trevor
>>>>
>>>>
>>>
>>> OK Here's a list of AVCs. I tried to cull the ones that seemed
>>> obviously not related (because they referred to an unrelated file
>>> or
>>> command) but there may be some extraneous ones left. These are from
>>> two
>>> commits. Interestingly, even though SELInux is in permissive mode,
>>> the
>>> commits failed with the same timeout message.
>>>
>>> [AVCs deleted]
>>>
>> Ok some of these AVCs can be allowed by booleans.
>>
>> httpd_use_execmem and httpd_can_network_connect.
>>
>> You can check it using audit2allow on these AVCs.
>>
>> For
>>
>>> [more AVCs deleted]
>>
>> I would open a new bug against selinux-policy component. It looks
>> like
>> something what we could allow by a boolean.
>>
> 
> I think I got it working with 
> 
>     module subgit-policy 1.0;
> 
>     require {
>     	    type httpd_sys_script_t;
>     	    type httpd_sys_rw_content_t;
>     	    type proc_net_t;
>     	    class process execmem;
>     	    class tcp_socket { accept listen };
>     	    class file { read execute open getattr };
>     }
> 
>     #============= httpd_sys_script_t ==============
>     allow httpd_sys_script_t httpd_sys_rw_content_t:file execute;

You will need to add labeling for a file which is executed and labeled
as httpd_sys_rw_content_t.

# chcon -t httpd_sys_script_exec_t PATHO/executable_file

for testing.

>     allow httpd_sys_script_t proc_net_t:file { read getattr open };

Ok, this one should be a part of httpd_can_network_connect boolean.

> 
>     #!!!! This avc can be allowed using the boolean 'httpd_execmem'
>     allow httpd_sys_script_t self:process execmem;
> 
>     #!!!! This avc can be allowed using one of the these booleans:
>     #     nis_enabled, httpd_can_network_connect
>     allow httpd_sys_script_t self:tcp_socket { accept listen };
> 
> and
> 
>     module pre-commit-policy 1.0;
> 
>     require {
>     	    type ephemeral_port_t;
>     	    type httpd_t;
>     	    type httpd_sys_script_t;
>     	    class process { siginh noatsecure rlimitinh };
>     	    class tcp_socket name_connect;
>     }
> 
>     #============= httpd_sys_script_t ==============
> 
>     #!!!! This avc can be allowed using one of the these booleans:
>     #     nis_enabled, httpd_can_network_connect
>     allow httpd_sys_script_t ephemeral_port_t:tcp_socket name_connect;
> 
>     #============= httpd_t ==============
>     allow httpd_t httpd_sys_script_t:process { siginh rlimitinh
>     noatsecure };
> 
> This is a CentOS system. Where is the best place to file the bug?
> 
> Thanks.
> 


-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux