From: dwalsh@redhat.com (Daniel J Walsh)
Date: Thu, 06 Feb 2014 16:50:16 +0100
Subject: [refpolicy] I would like to suggest that we remove the tmpfs_t
 and type alias them to tmp_t.
In-Reply-To: <52F39365.4020505@tresys.com>
References: <52F36FC1.4020001@redhat.com> <52F39365.4020505@tresys.com>
Message-ID: <52F3AF38.7050708@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

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 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?


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

iEYEARECAAYFAlLzrzgACgkQrlYvE4MpobMhWgCcCB6ovrsQfXq0fe/pdsZfCWH9
pcIAoIuipe2CH9bxC6yXBTHW3Eruwr7V
=o6Sg
-----END PGP SIGNATURE-----