From: domg472@gmail.com (Dominick Grift)
Date: Mon, 21 Feb 2011 20:24:10 +0100
Subject: [refpolicy] [patch 1/1] sudo: Fixes for sudo,
	handle /var/db/sudo
In-Reply-To: <4D62BBB0.4070208@redhat.com>
References: <4D5EA91C.1080409@redhat.com>
	<1298092089.3101.51.camel@tesla.lan>	<4D62706E.9090801@redhat.com>
	<4D6271B6.8020105@gmail.com> <4D6299D4.5030001@redhat.com>
	<4D62A3E8.80404@gmail.com> <4D62BBB0.4070208@redhat.com>
Message-ID: <4D62BBDA.1050907@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

On 02/21/2011 08:23 PM, Daniel J Walsh wrote:
> On 02/21/2011 12:42 PM, Dominick Grift wrote:
>> On 02/21/2011 05:59 PM, Daniel J Walsh wrote:
>>> On 02/21/2011 09:07 AM, Dominick Grift wrote:
>>>> On 02/21/2011 03:02 PM, Daniel J Walsh wrote:
>>>>> On 02/19/2011 12:08 AM, Guido Trentalancia wrote:
>>>>>> Hello Miroslav !
> 
>>>>>> On Fri, 18/02/2011 at 17.15 +0000, Miroslav Grepl wrote:
>>>>>>> http://mgrepl.fedorapeople.org/F15/admin_sudo.patch
>>>>>>>
>>>>>>>      * Allow sudo to send signals to any domains the user could have 
>>>>>>> transitioned to.
>>>>>>>      * Handle /var/db/sudo
>>>>>>>      * Allow users to run executables in /tmp or ~/
> 
>>>>>> To the best of my knowledge, the first part of the last change is
>>>>>> something really bad from a security point of view. 
> 
>>>>>> System administrators put much effort to avoid that (such as
>>>>>> mounting /tmp with noexec, nosuid options) !
> 
>>>>>> A legitimate user does not need to store his/her executables in /tmp, as
>>>>>> he/she has at least its own home directory available for that (and if
>>>>>> he/she cannot write there, then he/she is probably over quota).
> 
>>>>>> /tmp just "potentially provides storage space for malicious
>>>>>> executables" (quoted from paragraph 2.2.1.3 of NSA public document
>>>>>> "Guide to the Secure Configuration of Red Hat Enterprise Linux 5"
>>>>>> Revision 4, but any decent web search engine would easily provide you
>>>>>> with tons of pages relative to the cries of those whom have allowed that
>>>>>> sort of thing to happen on their systems).
> 
>>>>>> Regards,
> 
>>>>>> Guido
> 
>>>>>> _______________________________________________
>>>>>> refpolicy mailing list
>>>>>> refpolicy at oss.tresys.com
>>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
>>>>> +	userdom_domtrans_user_tmp($1_sudo_t, $3)
> 
>>>>> Says to run user_tmp_t files as staff_t, Which is the equivalent of if
>>>>> the staff_t had executed the file directly.
> 
>>>>> I guess if execution of homedir/tmp dir was turned off this could be
>>>>> seen as a priv escalation.
> 
>>>> refpolicy does not have the above functionality afaik.
> 
>>>>> staff_t is not allowed to execute user_tmp_t, but it can if it goes
>>>>> through sudo.
>>>> _______________________________________________
>>>> refpolicy mailing list
>>>> refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
>>> Are you saying staff_t is not allowed to execute user_tmp_t in reference
>>> policy?
> 
>> template(`userdom_login_user_template', `
>> 	gen_require(`
>> 		class context contains;
>> 	')
> 
>> 	userdom_base_user_template($1)
> 
>> 	userdom_manage_home_role($1_r, $1_t)
> 
>> 	userdom_manage_tmp_role($1_r, $1_t)
>> 	userdom_manage_tmpfs_role($1_r, $1_t)
> 
>> 	userdom_exec_user_tmp_files($1_t)
>> 	userdom_exec_user_home_content_files($1_t)
> 
>> 	userdom_change_password_template($1)
> 
>> 	##############################
>> 	#
>> 	# User domain Local policy
>> 	#
> Then allowing sudo to execute them as the user role would make sense.

agreed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1iu9oACgkQMlxVo39jgT8m3wCfTvob88yJZXYMQFQfWzGLK1zu
asMAoIB4ck8l+Y72r2YFTqO5MkwSCB1u
=GngS
-----END PGP SIGNATURE-----