From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 7 Feb 2014 10:36:06 -0500
Subject: [refpolicy] I would like to suggest that we remove the tmpfs_t
 and type alias them to tmp_t.
In-Reply-To: <52F3AF38.7050708@redhat.com>
References: <52F36FC1.4020001@redhat.com> <52F39365.4020505@tresys.com>
	<52F3AF38.7050708@redhat.com>
Message-ID: <52F4FD66.1030907@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

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