From dab5a01333f1f741b1abf8042d5ce5f59e1b4337 Mon Sep 17 00:00:00 2001 From: "Todd C. Miller" Date: Mon, 1 Feb 1999 00:45:02 +0000 Subject: [PATCH] clarify bad timestamp and fmt --- sudo.cat | 26 +++++++------- sudo.man | 102 ++++++++++++++++++++++++++----------------------------- sudo.pod | 102 ++++++++++++++++++++++++++----------------------------- 3 files changed, 111 insertions(+), 119 deletions(-) diff --git a/sudo.cat b/sudo.cat index cad6f5cb9..26cb69216 100644 --- a/sudo.cat +++ b/sudo.cat @@ -61,7 +61,7 @@ OOOOPPPPTTTTIIIIOOOONNNNSSSS -17/Jan/99 1.5.8 1 +26/Jan/99 1.5.8 1 @@ -119,15 +119,15 @@ SSSSEEEECCCCUUUURRRRIIIITTTTYYYY NNNNOOOOTTTTE ssssuuuuddddoooo tries to be safe when executing external commands. Variables that control how dynamic loading and binding is done can be used to subvert the program that ssssuuuuddddoooo runs. - To combat this the LD_*, SHLIB_PATH (HP-UX only), LIBPATH - (AIX only), and _RLD_* environment variables are removed + To combat this the LD_*, _RLD_*, SHLIB_PATH (HP-UX only), + and LIBPATH (AIX only) environment variables are removed from the environment passed on to all commands executed. - ssssuuuuddddoooo will also remove the IFS, ENV, BASH_ENV and KRB_CONF - variables as they too can pose a threat. + ssssuuuuddddoooo will also remove the IFS, ENV, BASH_ENV, KRB_CONF and + KRB5_CONFIG variables as they too can pose a threat. -17/Jan/99 1.5.8 2 +26/Jan/99 1.5.8 2 @@ -168,9 +168,10 @@ sudo(8) MAINTENANCE COMMANDS sudo(8) sudo will not honor timestamp files set far in the future. Timestamp files with a date greater than current_time + 2 - * TIMEOUT will be ignored and sudo will log the anomaly. - This is done to keep a user from creating his/her own - timestamp file with a bogus date. + * TIMEOUT will be ignored and sudo complain about a + "preposterous stampfile date". This is done to keep a + user from creating his/her own timestamp file with a bogus + date. FFFFIIIILLLLEEEESSSS /etc/sudoers file of authorized users. @@ -192,8 +193,7 @@ EEEENNNNVVVVIIIIRRRROOOONNNNMMMMEEEENNNNTTTT V - -17/Jan/99 1.5.8 3 +26/Jan/99 1.5.8 3 @@ -259,7 +259,7 @@ SSSSEEEEEEEE AAAALLLLSSSSOOOO -17/Jan/99 1.5.8 4 +26/Jan/99 1.5.8 4 @@ -325,6 +325,6 @@ sudo(8) MAINTENANCE COMMANDS sudo(8) -17/Jan/99 1.5.8 5 +26/Jan/99 1.5.8 5 diff --git a/sudo.man b/sudo.man index 0d632ea1d..954c3fbfc 100644 --- a/sudo.man +++ b/sudo.man @@ -2,8 +2,8 @@ ''' $RCSfile$$Revision$$Date$ ''' ''' $Log$ -''' Revision 1.27 1999/01/17 22:40:53 millert -''' crank version and regen files +''' Revision 1.28 1999/02/01 00:45:02 millert +''' clarify bad timestamp and fmt ''' ''' .de Sh @@ -96,7 +96,7 @@ .nr % 0 .rr F .\} -.TH sudo 8 "1.5.8" "17/Jan/99" "MAINTENANCE COMMANDS" +.TH sudo 8 "1.5.8" "26/Jan/99" "MAINTENANCE COMMANDS" .UC .if n .hy 0 .if n .na @@ -266,62 +266,58 @@ The \f(CW--\fR flag indicates that \fBsudo\fR should stop processing command line arguments. It is most useful in conjunction with the \f(CW-s\fR flag. .SH "RETURN VALUES" \fBsudo\fR quits with an exit value of 1 if there is a -configuration/permission problem or if \fBsudo\fR cannot execute -the given command. In the latter case the error string is -printed to stderr via \fIperror\fR\|(3). If \fBsudo\fR cannot \fIstat\fR\|(2) -one or more entries in the user's PATH the error is printed -on stderr via \fIperror\fR\|(3). (If the directory does not exist -or if it is not really a directory, the entry is ignored and -no error is printed.) This should not happen under normal -circumstances. The most common reason for \fIstat\fR\|(3) to return -\*(L"permission denied\*(R" is if you are running an automounter and -one of the directories in your PATH is on a machine that is -currently unreachable. +configuration/permission problem or if \fBsudo\fR cannot execute the +given command. In the latter case the error string is printed to +stderr via \fIperror\fR\|(3). If \fBsudo\fR cannot \fIstat\fR\|(2) one or more entries +in the user's PATH the error is printed on stderr via \fIperror\fR\|(3). +(If the directory does not exist or if it is not really a directory, +the entry is ignored and no error is printed.) This should not +happen under normal circumstances. The most common reason for +\fIstat\fR\|(3) to return \*(L"permission denied\*(R" is if you are running an +automounter and one of the directories in your PATH is on a machine +that is currently unreachable. .SH "SECURITY NOTES" -\fBsudo\fR tries to be safe when executing external commands. -Variables that control how dynamic loading and binding is -done can be used to subvert the program that \fBsudo\fR runs. -To combat this the \f(CWLD_*\fR, \f(CWSHLIB_PATH\fR (HP\-UX only), -\f(CWLIBPATH\fR (AIX only), and \f(CW_RLD_*\fR environment variables are -removed from the environment passed on to all commands executed. -\fBsudo\fR will also remove the \f(CWIFS\fR, \f(CWENV\fR, \f(CWBASH_ENV\fR -and \f(CWKRB_CONF\fR variables as they too can pose a threat. +\fBsudo\fR tries to be safe when executing external commands. Variables +that control how dynamic loading and binding is done can be used +to subvert the program that \fBsudo\fR runs. To combat this the +\f(CWLD_*\fR, \f(CW_RLD_*\fR, \f(CWSHLIB_PATH\fR (HP\-UX only), and \f(CWLIBPATH\fR (AIX +only) environment variables are removed from the environment passed +on to all commands executed. \fBsudo\fR will also remove the \f(CWIFS\fR, +\f(CWENV\fR, \f(CWBASH_ENV\fR, \f(CWKRB_CONF\fR and \f(CWKRB5_CONFIG\fR variables as +they too can pose a threat. .PP -To prevent command spoofing, \fBsudo\fR checks "." and "" (both -denoting current directory) last when searching for a command -in the user's PATH (if one or both are in the PATH). -Note, however, that the actual PATH environment variable -is \fInot\fR modified and is passed unchanged to the program that -\fBsudo\fR executes. +To prevent command spoofing, \fBsudo\fR checks "." and "" (both denoting +current directory) last when searching for a command in the user's +PATH (if one or both are in the PATH). Note, however, that the +actual PATH environment variable is \fInot\fR modified and is passed +unchanged to the program that \fBsudo\fR executes. .PP -For security reasons, if your OS supports shared libraries, -\fBsudo\fR should always be statically linked unless the -dynamic loader disables user-defined library search paths -for setuid programs. (Most modern dynamic loaders do this.) +For security reasons, if your OS supports shared libraries, \fBsudo\fR +should always be statically linked unless the dynamic loader disables +user-defined library search paths for setuid programs. (Most modern +dynamic loaders do this.) .PP \fBsudo\fR will check the ownership of its timestamp directory -(\fI/var/run/sudo\fR or \fI/tmp/.odus\fR by default) and ignore -the directory's contents if it is not owned by root and -only read, writable, and executable by root. On systems -that allow users to give files away to root (via chown), -if the timestamp directory is located in a directory writable -by anyone (ie: \fI/tmp\fR), it is possible for a user to create -the timestamp directory before \fBsudo\fR is run. -However, because \fBsudo\fR checks the ownership and mode of -the directory, the only damage that can be done is to \*(L"hide\*(R" -files by putting them in the timestamp dir. This is unlikely -to happen since once the timestamp dir is owned by root and -inaccessible by any other user the user placing files there -would be unable to get them back out. To get around this -issue you can use a directory that is not world-writable -for the timestamps (\fI/var/adm/sudo\fR for instance). +(\fI/var/run/sudo\fR or \fI/tmp/.odus\fR by default) and ignore the +directory's contents if it is not owned by root and only read, +writable, and executable by root. On systems that allow users to +give files away to root (via chown), if the timestamp directory is +located in a directory writable by anyone (ie: \fI/tmp\fR), it is +possible for a user to create the timestamp directory before \fBsudo\fR +is run. However, because \fBsudo\fR checks the ownership and mode of +the directory, the only damage that can be done is to \*(L"hide\*(R" files +by putting them in the timestamp dir. This is unlikely to happen +since once the timestamp dir is owned by root and inaccessible by +any other user the user placing files there would be unable to get +them back out. To get around this issue you can use a directory +that is not world-writable for the timestamps (\fI/var/adm/sudo\fR for +instance). .PP -\f(CWsudo\fR will not honor timestamp files set far in the -future. Timestamp files with a date greater than -current_time + 2 * \f(CWTIMEOUT\fR will be ignored and -sudo will log the anomaly. This is done to keep a user -from creating his/her own timestamp file with a bogus -date. +\f(CWsudo\fR will not honor timestamp files set far in the future. +Timestamp files with a date greater than current_time + 2 * \f(CWTIMEOUT\fR +will be ignored and sudo complain about a \*(L"preposterous stampfile +date\*(R". This is done to keep a user from creating his/her own +timestamp file with a bogus date. .SH "FILES" .PP .Vb 1 diff --git a/sudo.pod b/sudo.pod index 9f2010d8a..c7212daae 100644 --- a/sudo.pod +++ b/sudo.pod @@ -115,64 +115,60 @@ line arguments. It is most useful in conjunction with the C<-s> flag. =head1 RETURN VALUES B quits with an exit value of 1 if there is a -configuration/permission problem or if B cannot execute -the given command. In the latter case the error string is -printed to stderr via perror(3). If B cannot stat(2) -one or more entries in the user's PATH the error is printed -on stderr via perror(3). (If the directory does not exist -or if it is not really a directory, the entry is ignored and -no error is printed.) This should not happen under normal -circumstances. The most common reason for stat(3) to return -"permission denied" is if you are running an automounter and -one of the directories in your PATH is on a machine that is -currently unreachable. +configuration/permission problem or if B cannot execute the +given command. In the latter case the error string is printed to +stderr via perror(3). If B cannot stat(2) one or more entries +in the user's PATH the error is printed on stderr via perror(3). +(If the directory does not exist or if it is not really a directory, +the entry is ignored and no error is printed.) This should not +happen under normal circumstances. The most common reason for +stat(3) to return "permission denied" is if you are running an +automounter and one of the directories in your PATH is on a machine +that is currently unreachable. =head1 SECURITY NOTES -B tries to be safe when executing external commands. -Variables that control how dynamic loading and binding is -done can be used to subvert the program that B runs. -To combat this the C, C (HP-UX only), -C (AIX only), and C<_RLD_*> environment variables are -removed from the environment passed on to all commands executed. -B will also remove the C, C, C -and C variables as they too can pose a threat. - -To prevent command spoofing, B checks "." and "" (both -denoting current directory) last when searching for a command -in the user's PATH (if one or both are in the PATH). -Note, however, that the actual PATH environment variable -is I modified and is passed unchanged to the program that -B executes. - -For security reasons, if your OS supports shared libraries, -B should always be statically linked unless the -dynamic loader disables user-defined library search paths -for setuid programs. (Most modern dynamic loaders do this.) +B tries to be safe when executing external commands. Variables +that control how dynamic loading and binding is done can be used +to subvert the program that B runs. To combat this the +C, C<_RLD_*>, C (HP-UX only), and C (AIX +only) environment variables are removed from the environment passed +on to all commands executed. B will also remove the C, +C, C, C and C variables as +they too can pose a threat. + +To prevent command spoofing, B checks "." and "" (both denoting +current directory) last when searching for a command in the user's +PATH (if one or both are in the PATH). Note, however, that the +actual PATH environment variable is I modified and is passed +unchanged to the program that B executes. + +For security reasons, if your OS supports shared libraries, B +should always be statically linked unless the dynamic loader disables +user-defined library search paths for setuid programs. (Most modern +dynamic loaders do this.) B will check the ownership of its timestamp directory -(F or F by default) and ignore -the directory's contents if it is not owned by root and -only read, writable, and executable by root. On systems -that allow users to give files away to root (via chown), -if the timestamp directory is located in a directory writable -by anyone (ie: F), it is possible for a user to create -the timestamp directory before B is run. -However, because B checks the ownership and mode of -the directory, the only damage that can be done is to "hide" -files by putting them in the timestamp dir. This is unlikely -to happen since once the timestamp dir is owned by root and -inaccessible by any other user the user placing files there -would be unable to get them back out. To get around this -issue you can use a directory that is not world-writable -for the timestamps (F for instance). - -C will not honor timestamp files set far in the -future. Timestamp files with a date greater than -current_time + 2 * C will be ignored and -sudo will log the anomaly. This is done to keep a user -from creating his/her own timestamp file with a bogus -date. +(F or F by default) and ignore the +directory's contents if it is not owned by root and only read, +writable, and executable by root. On systems that allow users to +give files away to root (via chown), if the timestamp directory is +located in a directory writable by anyone (ie: F), it is +possible for a user to create the timestamp directory before B +is run. However, because B checks the ownership and mode of +the directory, the only damage that can be done is to "hide" files +by putting them in the timestamp dir. This is unlikely to happen +since once the timestamp dir is owned by root and inaccessible by +any other user the user placing files there would be unable to get +them back out. To get around this issue you can use a directory +that is not world-writable for the timestamps (F for +instance). + +C will not honor timestamp files set far in the future. +Timestamp files with a date greater than current_time + 2 * C +will be ignored and sudo complain about a "preposterous stampfile +date". This is done to keep a user from creating his/her own +timestamp file with a bogus date. =head1 FILES -- 2.40.0