From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 17 Mar 2014 10:03:27 -0400
Subject: [refpolicy] I would like to suggest that we remove the tmpfs_t
 and type alias them to tmp_t.
In-Reply-To: <52FA4331.5090408@redhat.com>
References: <52F36FC1.4020001@redhat.com> <52F39365.4020505@tresys.com>
	<52F3AF38.7050708@redhat.com> <52F4FD66.1030907@tresys.com>
	<52FA4331.5090408@redhat.com>
Message-ID: <532700AF.6050401@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 2/11/2014 10:35 AM, Daniel J Walsh wrote:
> On 02/07/2014 10:36 AM, Christopher J. PeBenito wrote:
>> On 02/06/14 10:50, Daniel J Walsh wrote:
>>> On 02/06/2014 02:51 PM, Christopher J. PeBenito wrote:
>>>> On 02/06/14 06:19, Daniel J Walsh wrote:
>>>>> - From a security point of view, treating this differently has
>>>>> little value in my mind.  I believe policy writers just write both
>>>>> rules in place.  I guess you could argue that combining them together
>>>>> would allow a domain to write to /dev/shm /tmp and /var/tmp and
>>>>> currently you could only write to one.
>>>>>
>>>>> What do people think about this?
>>>
>>>> I don't think I have any objections, though I'm eager to hear
>>>> opinions. However, I think we should probably still keep /dev/shm
>>>> separate.
>>>
>>> Well the goal is to prevent code like the following:
>>>
>>> manage_dirs_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t) 
>>> manage_files_pattern(aisexec_t, aisexec_tmp_t, aisexec_tmp_t) 
>>> files_tmp_filetrans(aisexec_t, aisexec_tmp_t, { dir file })
>>>
>>> manage_dirs_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t) 
>>> manage_files_pattern(aisexec_t, aisexec_tmpfs_t, aisexec_tmpfs_t) 
>>> fs_tmpfs_filetrans(aisexec_t, aisexec_tmpfs_t, { dir file })
>>>
>>> We have this policy written everywhere.  Having /dev/shm labeled
>>> differently then /tmp means we still need to have this, which kills the
>>> idea.
> 
>> I understand.  I'd like to get rid of the duplication too.  This prompts
>> the question, how much of the tmpfs stuff is due to standard /dev/shm use
>> (i.e. SysV shared memory) vs. people mounting a tmpfs at /tmp?  It might
>> make sense to keep the fs labeled tmpfs_t, but filetrans to foo_tmp_t.  And
>> then when we have a case of a domain that has tmpfs and tmp objects, then
>> they can still be split out into foo_tmp_t and foo_tmpfs_t if another
>> domain accesses it's tmpfs files.
> 
>>> I would like to know what the security difference is between writing
>>> content to /dev/shm and /tmp?  Does anyone actually do anything when
>>> getting an AVC with a domain writing to /dev/shm other then allow the
>>> domain to write there?
> 
>> A shared memory segment is different than a temp file.
> 
> Yes /dev/shm is mainly for SysV Shared Memory, which we were trying to stop
> labeling altogether.  But it turns out that these could be attacked if they do
> not have labeling.  Which means we have to add file type transitions to all
> objects that use SysV Shared Memory.  This is actually what caused me to ask
> for this in the first place.
> 
> Labeling /dev/shm as shm_t or tmpfs_t and then transitioning to foobar_tmp_t
> is fine with me, also.  Especially if we change files_tmp_filetrans to call
> fs_tmpfs_filetrans :^).

I've been poking at this for a while, and what I've concluded is that we can merge the tmpfs types into tmp type, as long as the domain doesn't have any shm usage, under the assumption that the domain is using tmpfs as a regular tmp dir.  If I'm counting correctly, it looks like half the domains that have *_tmpfs_t usage could potentially merge it into their *_tmp_t.

What's odd is that I found that some domains that do have shm rules but don't have tmpfs rules, which makes me wonder if the shm rules are valid (or can you do shm w/o tmpfs usage?).

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