nagios_log_t missing

[Daniel J Walsh]

Farkas Levente wrote:

> Daniel J Walsh wrote:
>
>> Farkas Levente wrote:
>>
>>> Daniel J Walsh wrote:
>>>
>>>> Farkas Levente wrote:
>>>>
>>>>> hi,
>>>>> there is a nagios_log_t and used in nagios.fc but never defined 
>>>>> (missing). so when we try to apply it we got these errors:
>>>>> ---------------------------------------------
>>>>> # chcon -R -t nagios_log_t /var/log/nagios
>>>>> chcon: failed to change context of /var/log/nagios to 
>>>>> system_u:object_r:nagios_log_t: Invalid argument
>>>>> chcon: failed to change context of /var/log/nagios/rw to 
>>>>> system_u:object_r:nagios_log_t: Invalid argument
>>>>> chcon: failed to change context of /var/log/nagios/archives to 
>>>>> system_u:object_r:nagios_log_t: Invalid argument
>>>>> chcon: failed to change context of /var/log/nagios/.bash_history 
>>>>> to user_u:object_r:nagios_log_t: Invalid argument
>>>>> ---------------------------------------------
>>>>> how can i fix it?
>>>>> dan could you create updated rpms which fix it in 
>>>>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-)
>>>>> yours.
>>>>>
>>>> nagios policy is not used in RHEL4.  It should run unconfined_t.  
>>>> We are only supporting the subset of network daemons in targeted 
>>>> policy.
>>>>
>>>> Using strict or other policies in RHEL4 requires a separate support 
>>>> contract, professional services engagement.
>>>
>>>
>>>
>>>
>>> ok. i only think that if nagios_log_t used in the current 
>>> selinux-policy-targeted than (in nagios.fc) than it should have to 
>>> be defined also. but it's definition currently missing from 
>>> selinux-policy-targeted, which is imho a bug. that's what i'd like 
>>> to report.
>>
>>
>>
>> We do not strip out fc files that we do not support.  The way the 
>> make file and hence the RPM works is it looks for *.te files in the 
>> domains/program directory and uses those names to choose the 
>> file_context files.  We want to use the same policy source pool to
>> supoort targeted, strict, mls ... policy.  And therefore get the best 
>> bang for the buck from the open source community.  So think of the
>> policy-src files like you do kernel sources.  Just because there is 
>> stuff in there does not mean we support them.
>
>
> the question what does the 'support' means? ie. in the kernel source 
> there are unused part (ie. not compiled in the current kernel), but 
> you can recompile it so you can use that part to. which means the 
> source are coherent and there is not any reference to undefine type. 
> in this case nagios.fc refere to a type nagios_log_t which is not 
> defined anywhere. since you delete all unused .te files why? if you 
> don't strip fc files while do you strip te files? why dont you simple 
> ship with the policy-source and those who would like to use 
> unsupported programs can simple add it (moved from unused to ..) and 
> make reload. that owuld be much better, easier and cleaner the the 
> current case when everyone start to hack their own systems. i'm sure 
> many system used a few unsupported daemons.

Because I don't want people moving arbitrary files into targeted 
policy.  That is why they are removed.  If I left them there, people 
would go into the unused directory move a file into place rebuild and 
things would blow up.  The policy files are setup for the default of 
strict policy.  Targeted
policy is built differently.  (So is MLS).  The bug is that I have not 
removed the FC files. 

Support means whether I pay attention to a bug report in bugzilla or 
not.  Same with kernel.  Just because their is a configuration 
capability in the kernel sources, does not mean that if you build it an 
arbitrary way, your bugzilla is going to get action.  Now when we get to 
RHEL support
their it is even more formal.

>
>>> another thing even if nagios run in unconfined_t is ok since the log 
>>> files can be generated and the daemon is running, but the web 
>>> interface of nagios not working since it's try to read it's log 
>>> files under /var/log/nagios which is currently var_log_t (inherited 
>>> from it's parent). so currently i've a few options:
>>> - add a local.te as:
>>>   allow httpd_sys_script_t var_log_t:dir search;
>>>   allow httpd_sys_script_t var_log_t:file { getattr read };
>>> - change /var/log/nagios to httpd_sys_content_t and add only
>>>   allow httpd_sys_script_t var_log_t:dir search;
>>> - change /var/log/nagios to nagios_log_t and add
>>>   allow httpd_sys_script_t var_log_t:dir search;
>>>   allow httpd_sys_script_t nagios_log_t:file { getattr read };
>>> and imho the best solution would be to add this last one to the 
>>> global policy.
>>> yours.
>>>
>> How about adding
>> chcon -R -t httpd_sys_script_ro_t /var/log/nagios
>>
>> Then you don't need to change policy at all
>
>
> still need to add:
> allow httpd_sys_script_t var_log_t:dir search;
>
Probably not a good idea to give this in general.   You would need to 
add this to your local policy or run your script as 
httpd_unconfinet_script_t.



--