From: dwalsh@redhat.com (Daniel J Walsh)
Date: Tue, 11 Feb 2014 10:35:13 -0500
Subject: [refpolicy] I would like to suggest that we remove the tmpfs_t
 and type alias them to tmp_t.
In-Reply-To: <52F4FD66.1030907@tresys.com>
References: <52F36FC1.4020001@redhat.com> <52F39365.4020505@tresys.com>
	<52F3AF38.7050708@redhat.com> <52F4FD66.1030907@tresys.com>
Message-ID: <52FA4331.5090408@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 :^).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlL6QzEACgkQrlYvE4MpobP8EQCfXyAjZsaqQAbzLtXwsBcZqQ0j
7JYAn30i3yg42tJp4amdzNjHeNCGi25Z
=K+L+
-----END PGP SIGNATURE-----