[refpolicy] [patch 1/3] Implementation of system conf type

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 03/03/11 09:36, Guido Trentalancia wrote:
> On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
>> On 03/01/11 15:41, Guido Trentalancia wrote:
>>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
>>>> On 02/22/11 11:18, Guido Trentalancia wrote:
>>>>> On Tue, 22/02/2011 at 10.46 -0500, Christopher J. PeBenito wrote:
>>>>>> On 02/21/11 15:11, Guido Trentalancia wrote:
>>>>>>> On Mon, 21/02/2011 at 10.40 -0500, Daniel J Walsh wrote:
>>>>>>>> On 02/20/2011 12:37 AM, Guido Trentalancia wrote:
>>>>>> I don't understand why system-config-firewall would need to write to
>>>>>> etc_t, the iptables rules have their own labeling:
>>>>>>
>>>>>> /etc/sysconfig/ip6?tables.*     --
>>>>>> gen_context(system_u:object_r:iptables_conf_t,s0)
>>>>>> /etc/sysconfig/system-config-firewall.* --
>>>>>> gen_context(system_u:object_r:iptables_conf_t,s0)
>>>>>>
>>>>>>> Yes, this is very important. But isn't etc_runtime_t what is needed here
>>>>>>> then ?
>>>>>>
>>>>>> No, the purpose of that type is for generated files such as /.autofsck
>>>>>> and /etc/motd.
>>>>>
>>>>> Well then I think we need to check a few labels:
>>>>>
>>>>> /etc/smartd\.conf.*     --      system_u:object_r:etc_runtime_t:s0
>>>>> /etc/reader\.conf       --      system_u:object_r:etc_runtime_t:s0
>>>>
>>>> Right, these need to be reevaluated.
>>>
>>> I suppose you are going to take care of that.
>>
>> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
>> the below four lines should be removed.
>>
>>>>> And there is also other stuff that is not automatically-generated (if
>>>>> that is what you meant for "generated"):
>>>>>
>>>>> /etc/motd       --      system_u:object_r:etc_runtime_t:s0
>>>>> /etc/issue      --      system_u:object_r:etc_runtime_t:s0
>>>>> /etc/HOSTNAME   --      system_u:object_r:etc_runtime_t:s0
>>>>> /etc/issue\.net --      system_u:object_r:etc_runtime_t:s0
>>>>
>>>> These can be generated out of init scripts.  For example, Fedora used to
>>>> generate /etc/issue out of a init script.  It doesn't look like they do
>>>> that anymore, so perhaps we should reconsider these too
>>>>
>>>>> All the above mentioned files are configuration files by all means. Not
>>>>> that it's an urgent matter, but according to what you just said, then
>>>>> etc_runtime_t is possibly misplaced there...
>>>
>>> Yes, some distributions generate very generic banners with the name of
>>> the distribution and the version. But they are just meant to be examples
>>> (similarly to generic configuration files installed by default in /etc
>>> by most packages).
>>>
>>> They are static, so etc_t is what we need here.
> 
> I also take the opportunity to remind you of the issue with mtab lock
> files that I had already mentioned a few days ago.
> 
> Basically, mount tries to create lock files named:
> 
> /etc/mtab~<pid>
> 
> where <pid> gets substituted with the process id of mount itself.
> 
> Unfortunately at the moment these files are currently falling back to
> the etc_t label. It is very much desirable to have them labeled
> etc_runtime_t to avoid problems (denials) with write operations.
> 
> Originally the name for those lock files was /etc/mtab~. To avoid race
> conditions it was decided to append the <pid>. The source code is
> designed so that the upper bound for the length of <pid> is 20.
> 
> Please note that contrary to what is stated in the source code for mount
> (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> "/etc/mtab~.<pid>") !
> 
> Can somebody please take care of this ?

I don't see why this would be happening.  There are the following rules
in mount:

files_manage_etc_runtime_files(mount_t)
files_etc_filetrans_etc_runtime(mount_t, file)

So the file should be created with etc_runtime_t.  The only reasons I
can think of this mtab~<pid> file having etc_t are

1. it was there already and someone did a relabel
2. some new SELinux logic in it that does a matchpathcon on the filename
and then does setfscreatecon() to that context.

So if either of those is the case, you could add a file context entry to
try to fix it.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com