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 ~/
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
On Fri, Feb 18, 2011 at 05:15:08PM +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 ~/
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
#
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
-----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-----
-----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-----