Skip to contentSkip to conversation

sudo: Fixes for sudo, handle /var/db/sudo

PATCH New Miroslav Grepl 5 participants 10 messages Feb 18, 2011 – Feb 21, 2011

lore
Share & tools
lore
#1 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

#2 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 27 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

Quoted 8 lines

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.

staff_t is not allowed to execute user_tmp_t, but it can if it goes through sudo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1icG4ACgkQrlYvE4MpobO/SgCcCeagx2SuBd2InuVNk25YXt4b agEAoJOxwZz4QbXFkUrUGjvovKVFutO0
=bNTO
-----END PGP SIGNATURE-----

#3 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 2 lines

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

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

iEYEARECAAYFAk1icbYACgkQMlxVo39jgT/GvACgyv0XE7K8itnxMpdPE6KX90T+ 69sAnA9YTka3AzqlYMwtNtSTmk/7ozEW
=Gfmf
-----END PGP SIGNATURE-----

#4 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 46 lines · Dominick Grift
Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 9 lines

refpolicy does not have the above functionality afaik.

Quoted 2 lines

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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1imdQACgkQrlYvE4MpobOCDQCgx8Muc05F6plnR0yIlm5t/b92 u/YAn1lae+qK824+cC2wNdCQMiHT+/Mb
=qTCp
-----END PGP SIGNATURE-----

#5 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 56 lines · Daniel J Walsh
Quoted 46 lines · Dominick Grift
Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 8 lines

refpolicy does not have the above functionality afaik.

Quoted 2 lines

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

Quoted 7 lines

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

no, i am saying it can by default.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1io6UACgkQMlxVo39jgT+BJwCfZ1uAiEHtttA+U/zhWWOLkEA2 7dAAoJBH1EkeVT4Weu3p4VRilE+hRyDf
=ibFC
-----END PGP SIGNATURE-----

#6 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

In reply to Daniel J Walsh

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

Quoted 56 lines · Daniel J Walsh
Quoted 46 lines · Dominick Grift
Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 8 lines

refpolicy does not have the above functionality afaik.

Quoted 2 lines

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

Quoted 7 lines

_______________________________________________
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
	#

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

iEYEARECAAYFAk1io+gACgkQMlxVo39jgT/B3ACdEcmdX4QetgfqL7bR5wRjtbBB ta8An0OKplN4Xd4XlLUllL3AMAAGMJrx
=9dkE
-----END PGP SIGNATURE-----

#7 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 78 lines · Dominick Grift
Quoted 56 lines · Daniel J Walsh
Quoted 46 lines · Dominick Grift
Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 8 lines

refpolicy does not have the above functionality afaik.

Quoted 2 lines

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

Quoted 7 lines

_______________________________________________
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)
Quoted 8 lines
	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. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1iu7AACgkQrlYvE4MpobMb4gCeOpC4k1tN/TOFmGnlBOm9Pozc 8GIAoOMnXXtndesKbFdNSOcH5vn2ufiR
=VyWU
-----END PGP SIGNATURE-----

#8 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

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

Quoted 81 lines · Daniel J Walsh
Quoted 79 lines · Dominick Grift
Quoted 56 lines · Daniel J Walsh
Quoted 46 lines · Dominick Grift
Quoted 39 lines · Daniel J Walsh
Quoted 35 lines · Guido Trentalancia

Hello Miroslav !

Quoted 6 lines · Miroslav Grepl

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

(quoted diff) +1 -0
+	userdom_domtrans_user_tmp($1_sudo_t, $3)
Quoted 5 lines

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.

Quoted 8 lines

refpolicy does not have the above functionality afaik.

Quoted 2 lines

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

Quoted 7 lines

_______________________________________________
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)
Quoted 7 lines
Quoted 6 lines
	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-----

#9 lore raw

PATCH 1/1 sudo: Fixes for sudo, handle /var/db/sudo

In reply to Miroslav Grepl
Quoted 6 lines · Miroslav Grepl

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 ~/

The /var/db/sudo use was discussed not that long ago. As it is a rename from /var/run/sudo to /var/db/sudo (or /var/lib/sudo or /var/adm/sudo) the previous mapping (pam_var_run_t) should be applied rather than create a new type.

Wkr,
Sven Vermeulen