sudo-project / sudo Goto Github PK

Utility to execute a command as another user

License: Other

Makefile 7.83% Shell 8.64% M4 3.08% C 72.09% Perl 0.66% Yacc 0.95% Lex 0.49% Pascal 0.44% C++ 0.10% Python 0.34% Roff 5.34% Dockerfile 0.04%

sudo's Introduction

The sudo philosophy

Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done.

Where to find sudo

Before building sudo, make sure you have the current version. The latest sudo may always be gotten via anonymous ftp from ftp.sudo.ws in the directory /pub/sudo/ or from the sudo web site, https://www.sudo.ws/

The distribution is sudo-M.m.tar.gz where M is the major version number and m is the minor version number. Beta versions of sudo may also be available. If you join the sudo-workers mailing list you will get the beta announcements (see the Mailing lists section below).

What's new

See the NEWS file for a list of major changes in this release. For a complete list of changes, see the ChangeLog. For a summary of major changes to the current stable release, see https://www.sudo.ws/releases/stable/.

If you are upgrading from an earlier version of Sudo, read docs/UPGRADE.md for information on changes in behavior that may affect you.

For a history of sudo see docs/HISTORY.md. You can find a list of contributors to sudo in docs/CONTRIBUTORS.md.

Building the release

Read the installation guide, INSTALL.md, before trying to build sudo. Pay special attention to the "OS dependent notes" section.

How to contribute

See docs/CONTRIBUTING.md for information on how you can help contribute to sudo.

Copyright

Sudo is distributed under an ISC-style license. Refer to LICENSE.md for details.

Mailing lists

sudo-announce

This list receives announcements whenever a new version of sudo is released. https://www.sudo.ws/mailman/listinfo/sudo-announce

sudo-blog

This list receives a message when a new sudo blog article is available. https://www.sudo.ws/mailman/listinfo/sudo-blog

sudo-commits

This list receives a message for each commit made to the sudo source repository. https://www.sudo.ws/mailman/listinfo/sudo-commits

sudo-users

This list is for questions and general discussion about sudo. https://www.sudo.ws/mailman/listinfo/sudo-users

sudo-workers

This list is for people working on and porting sudo. https://www.sudo.ws/mailman/listinfo/sudo-workers

To subscribe to a list, visit its url (listed above) and enter your email address to subscribe. Digest versions are available but these are fairly low traffic lists so the digest versions are not a significant win.

Mailing list archives are also available. See the mailing list web sites for the appropriate links.

Sudo web page

There is a sudo web page at https://www.sudo.ws/ that contains documentation, downloads, a bug tracker, the source repo, the sudo blog, information about beta versions and other useful info.

Filing bug reports/issues

If you believe you have found a bug, you can either file a bug report in the sudo bug database, https://bugzilla.sudo.ws/, or open a GitHub issue, whichever you find easier. If you would prefer to use email, messages may be sent to the [email protected] mailing list (public) or to [email protected] (private).

For sudo's security policy and how to report security issues, see docs/SECURITY.md.

Please check docs/TROUBLESHOOTING.md before submitting a bug report. When reporting bugs, be sure to include the version of sudo you are using, the operating system and/or distro that is affected, and, if possible, step-by-step instructions to reproduce the problem.

sudo's People

Contributors

Stargazers

Watchers

Forkers

aixoss radosroka bonki guoxiao aixtools abhi-jha guillemj nirs tongla banro21 ttwno millert manner82 freeguy1 edneville toddmiller1 laczau sarahefakler bsmr nikparam42 infernalheaven bryanasdev000 kashish-miglani dsandler khubaibumer maurice-schuppe dlrobertson sebras gaiareader nautilusshell athorp96 lehmier collinalexbell linuxrocks2000 santloda frazerclews evan-a-a iagox86 sarahmalzahrani iwonasado gusmarmedina3 felinae98 whzhe51 pbrezina rabbitt 0101binary0101 1ndevelopment greyltc davidkorczynski redacid superzang icodein meteorite66 thebeanogamer mrg0ne arafatx colmmacc persianyagami90xs jake01756 dima9777 arceeboy jiangkun1991 lnsongxf floodnut dulatello08 orbea charlenchen c4pt000 pom odkr mertsa reallos bbschang acidburn0zzz stephcoutts ma27 haydenroche5 larb0b solarysdev psasidhar rtoax queilawithaq kanavin virtualcabinet arianabbasi1389 azurecloudmonk excloudx6 tyler887 blvckcoca tylerreese violethaze74 yaolianwei matchpointdarko simotek svusal 10maurycy10 noah-wagner dfskoll val-verde yvettep321

sudo's Issues

Let developers give a reason for needing sudo

I was working on a script and had this idea, so I just thought why not mention it.

It would be nice to have an argument that lets a developer add a reason for wanting superuser privileges in their scripts. This would let them be more transparent to users as to why sudo is needed. You could also have the reason added to the system log.

Of course, this wouldn't stop someone from using superuser privileges for something malicious, but it would be nice to know why a script/program from a trusted source is requesting superuser privileges.

Example:
A script is being used to install x program on a Debian-based system and sudo is needed to install dependencies via apt:

sudo -r "Need to install dependencies" apt install pkg1 pkg2...

(Potential) Result:
[sudo] Reason: Need to install dependencies.
[sudo] password for user:

Allow skipping fingerprint pam module when using -A

I have a fingerprint reader on my laptop and fedora configures pam_fprintd.so to be tried before pam_unix.so. When I run sudo as part of a script (pyinfra in my case, but ansible has the same problem), no tty is there so sudo will authenticate every call. Unfortunately, sudo now waits for the pam_fprintd.so to timeout (or me authenticating it) and then use pam_unix.so which asks for a password and gets one via the SUDO_ASKPASS command.

Given that sudo knows that the authentication should happen via password, it makes no sense to ask for the fingerprint, but I currently see no way to disable pam_fprintd.so in only such cases.

One solution for this (in sudo) would be if sudo could install a separate pam.d service for cases where it's called with -A. A user (or hopefully distros/authselect) could then configure authentications for such cases without pam_fprintd.so (or just add the pam_unix.so earlier than pam_fprintd.so).

plugins/sudoers/editor.c wordsplit() can be off by one depending on string

Discovered this bug while I was trying to read the source code to figure out how sudo works inspired by @LiveOverflow's video on this topic :)

In plugins/sudoers/editor.c line 74-78 appear to increment the pointer *cp by two when a \ is encountered (once before the continue statement, once before the start of the next iteration). So when the environment variable EDITOR is set using export EDITOR='/usr/bin/vi\\', *last in Line 85 is set to a location that is 1 + the length of the string which is beyond the NULL pointer for that string.

Convenience link to the code in question:

sudo/plugins/sudoers/editor.c

Lines 73 to 85 in a85c6b4

 /* Scan str until we encounter white space. */ 

 for (cp = str; cp < endstr; cp++) { 

 if (*cp == '\\') { 

 /* quoted char, do not interpret */ 

 cp++; 

 continue; 

 } 

 if (*cp == ' ' || *cp == '\t') { 

 /* end of word */ 

 break; 

 } 

 } 

 *last = cp;

Log exit status of command run by sudo

Please log exit status of a command run by sudo in sudoers_policy_close() so one can find out how it ended when reading the log.

New log server/client feature does not compile on HP-UX with HP aCC

Trying from master on HP-UX 11.31:

export PREFIX=/opt/ports
export LIBDIR=$PREFIX/lib/hpux32
export SYSCONFDIR=$PREFIX/etc
export CC=/opt/aCC/bin/aCC
export CXX=/opt/aCC/bin/aCC
export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
export CPPFLAGS="-I$PREFIX/include"
export LDFLAGS="-L$LIBDIR"
$CONFIGURE --sysconfdir=$SYSCONFDIR --disable-root-sudo --disable-sasl --disable-pam-session \
  --with-env-editor --without-ldap --disable-shared-libutil --enable-static-sudoers \
  --enable-gss-krb5-ccache-name

gives me errors like this:

"./iolog_client.c", line 736: error #2136: struct "_ClientMessage" has no
          field "hello_msg"
      client_msg.hello_msg = &hello_msg;
                 ^

The reason is that anonymous unions are not standard (ANSI) C. I have reported the same issue with GNU coreutils, see:

Here is a working patch:
anon-union.patch.txt

New sudo.conf makes statically compiled sudo unusable

Compiled from master on HP-UX with aCC:

$CONFIGURE --sysconfdir=$SYSCONFDIR --disable-root-sudo --disable-sasl --disable-pam-session \
  --with-env-editor --without-ldap --disable-shared-libutil --enable-static-sudoers \
  --disable-log-server --disable-log-client --enable-gss-krb5-ccache-name

Note: --disable-shared-libutil --enable-static-sudoers.

/opt/ports/etc/sudo.conf contains:

Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
Plugin sudoers_audit sudoers.so

but sudoers.so is not present:

osipovmi@deblndw024v:/var/tmp/ports/work/sudo (master *%=)
$ find /opt/ports -name sudoers.so
osipovmi@deblndw024v:/var/tmp/ports/work/sudo (master *%=)
$ ll /opt/ports/libexec/sudo/
total 3310
-r-xr-xr-x 1 root root   1026 2020-09-03 10:36 audit_json.la*
-r-xr-xr-x 1 root root 828124 2020-09-03 10:36 audit_json.so*
-r-xr-xr-x 1 root root   1026 2020-09-03 10:36 group_file.la*
-r-xr-xr-x 1 root root 827544 2020-09-03 10:36 group_file.so*
-r-xr-xr-x 1 root root   1056 2020-09-03 10:36 sample_approval.la*
-r-xr-xr-x 1 root root 823920 2020-09-03 10:36 sample_approval.so*
-r-xr-xr-x 1 root root    954 2020-09-03 10:36 sudo_noexec.la*
-r-xr-xr-x 1 root root  74984 2020-09-03 10:36 sudo_noexec.so*
-r-xr-xr-x 1 root root   1038 2020-09-03 10:36 system_group.la*
-r-xr-xr-x 1 root root 822288 2020-09-03 10:36 system_group.so*

and when I start sudo it says:

$ LANG=C sudo
sudo: error in /opt/ports/etc/sudo.conf, line 16 while loading plugin "sudoers_audit"
sudo: unable to find symbol "sudoers_audit" in sudoers.so
sudo: fatal error, unable to load plugins

as soon as I remove Plugin sudoers_audit sudoers.so sudo does work.

Did I do anything or is this a config glitch?

`sudo` always seem to create a "monitor" process

I'm using OpenSUSE Tumbleweed, which just updated sudo to v1.9.4. Previously I would assume I had at least v1.9.2 given how quickly packages get into Tumbleweed repositories.

However even though currently I have Defaults !use_pty, !pam_session, !pam_setcred in my /etc/sudoers file (and there are no other files under /etc/sudoers.d), sudo always seems to start a monitor process that waits for the executed one to finish. Previously those options disabled this monitor process.

I have just downgraded sudo to 1.8.22 and the issue doesn't seem to be present, thus my assumption is that something broke in the latest 1.9.x releases, or perhaps there is another option enabled by default that requires a monitor process.

Cannot dynamically link on HP-UX with HP aCC

This has been giving me a hard time to understand. Compiling master on HP-UX 11.31 with HP aCC 6.29:

export PREFIX=/opt/ports
export LIBDIR=$PREFIX/lib/hpux32
export SYSCONFDIR=$PREFIX/etc
export CC=/opt/aCC/bin/aCC
export CXX=/opt/aCC/bin/aCC
export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
export CPPFLAGS="-I$PREFIX/include"
export LDFLAGS="-L$LIBDIR"
$CONFIGURE --sysconfdir=$SYSCONFDIR --disable-root-sudo --disable-sasl --disable-pam-session   --with-env-editor --without-ldap --disable-log-server --disable-log-client --enable-gss-krb5-ccache-name

gives me

libtool: link: ( cd ".libs" && rm -f "system_group.la" && ln -s "../system_group.la" "system_group.la" )
        /opt/aCC/bin/aCC -Ae -c -I../include -I.. -I. -I. -D_PATH_SUDO_CONF=\"/opt/ports/etc/sudo.conf\"  -DLOCALEDIR=\"/opt/ports/share/locale\" -I/opt/ports/include -D_XOPEN_SOURCE=600 -DZLIB_CONST -D_FORTIFY_SOURCE=2 -g -Bhidden_def    ./env_hooks.c
"./env_hooks.c", line 61: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "getenv" (declared at line 212 of
          "/usr/include/stdlib.h")
  getenv(const char *name)
  ^

"./env_hooks.c", line 133: warning #2147-D: declaration is incompatible with
          "int putenv(char *)" (declared at line 341 of
          "/usr/include/stdlib.h")
  putenv(PUTENV_CONST char *string)
  ^

"./env_hooks.c", line 133: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "putenv" (declared at line 341 of
          "/usr/include/stdlib.h")
  putenv(PUTENV_CONST char *string)
  ^

"./env_hooks.c", line 205: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "setenv" (declared at line 58 of
          "/usr/include/stdlib.h")
  setenv(const char *var, const char *val, int overwrite)
  ^

"./env_hooks.c", line 273: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "unsetenv" (declared at line 59 of
          "/usr/include/stdlib.h")
  unsetenv(const char *var)
  ^

4 errors detected in the compilation of "./env_hooks.c".
*** Fehlerrückkehrcode 2

Stopp.
*** Fehlerrückkehrcode 1

Stopp.

applied the following patch:


diff --git a/src/env_hooks.c b/src/env_hooks.c
index 5f9a61c75..b6f845bc1 100644
--- a/src/env_hooks.c
+++ b/src/env_hooks.c
@@ -57,7 +57,7 @@ getenv_unhooked(const char *name)
     return val;
 }

-sudo_dso_public char *
+ char *
 getenv(const char *name)
 {
     char *val = NULL;
@@ -129,7 +129,7 @@ putenv_unhooked(PUTENV_CONST char *string)
     return rpl_putenv(string);
 }

-sudo_dso_public int
+ int
 putenv(PUTENV_CONST char *string)
 {
     switch (process_hooks_putenv((char *)string)) {
@@ -201,7 +201,7 @@ setenv_unhooked(const char *var, const char *val, int overwrite)
     return rpl_setenv(var, val, overwrite);
 }

-sudo_dso_public int
+ int
 setenv(const char *var, const char *val, int overwrite)
 {
     switch (process_hooks_setenv(var, val, overwrite)) {
@@ -266,9 +266,9 @@ unsetenv_unhooked(const char *var)
 }

 #ifdef UNSETENV_VOID
-sudo_dso_public void
+ void
 #else
-sudo_dso_public int
+ int
 #endif
 unsetenv(const char *var)
 {

and now this one

libtool: compile:  /opt/aCC/bin/aCC -Ae -c -I../include -I.. -I. -I. -D_PATH_SUDO_CONF=\"/opt/ports/etc/sudo.conf\" -DLOCALEDIR=\"/opt/ports/share/locale\" -I/opt/ports/include -DZLIB_CONST -D_FORTIFY_SOURCE=2 -g -Bhidden_def ./sudo_noexec.c  -DPIC -o .libs/sudo_noexec.o
"./sudo_noexec.c", line 123: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execl" (declared at line 101 of
          "/usr/include/sys/unistd.h")
  DUMMY_VA(execl, const char *, const char *)
           ^

"./sudo_noexec.c", line 124: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execle" (declared at line 102 of
          "/usr/include/sys/unistd.h")
  DUMMY_VA(execle, const char *, const char *)
           ^

"./sudo_noexec.c", line 125: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execlp" (declared at line 103 of
          "/usr/include/sys/unistd.h")
  DUMMY_VA(execlp, const char *, const char *)
           ^

"./sudo_noexec.c", line 126: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execv" (declared at line 104 of
          "/usr/include/sys/unistd.h")
  DUMMY2(execv, const char *, char * const *)
         ^

"./sudo_noexec.c", line 127: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execvp" (declared at line 106 of
          "/usr/include/sys/unistd.h")
  DUMMY2(execvp, const char *, char * const *)
         ^

"./sudo_noexec.c", line 128: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "execve" (declared at line 105 of
          "/usr/include/sys/unistd.h")
  DUMMY3(execve, const char *, char * const *, char * const *)
         ^

"./sudo_noexec.c", line 160: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "system" (declared at line 213 of
          "/usr/include/stdlib.h")
  DUMMY1(system, const char *)
         ^

"./sudo_noexec.c", line 163: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "popen" (declared at line 644 of
          "/usr/include/stdio.h")
  FN_NAME(popen)(const char *c, const char *t)
          ^

"./sudo_noexec.c", line 178: error #3389-D: redeclaration cannot add
          dllexport/dllimport to "wordexp" (declared at line 75 of
          "/usr/include/wordexp.h")
  FN_NAME(wordexp)(const char *words, wordexp_t *we, int flags)
          ^

9 errors detected in the compilation of "./sudo_noexec.c".
*** Fehlerrückkehrcode 1

Stopp.
*** Fehlerrückkehrcode 1

Stopp.

another patch

diff --git a/src/env_hooks.c b/src/env_hooks.c
index 5f9a61c75..b6f845bc1 100644
--- a/src/env_hooks.c
+++ b/src/env_hooks.c
@@ -57,7 +57,7 @@ getenv_unhooked(const char *name)
     return val;
 }

-sudo_dso_public char *
+ char *
 getenv(const char *name)
 {
     char *val = NULL;
@@ -129,7 +129,7 @@ putenv_unhooked(PUTENV_CONST char *string)
     return rpl_putenv(string);
 }

-sudo_dso_public int
+ int
 putenv(PUTENV_CONST char *string)
 {
     switch (process_hooks_putenv((char *)string)) {
@@ -201,7 +201,7 @@ setenv_unhooked(const char *var, const char *val, int overwrite)
     return rpl_setenv(var, val, overwrite);
 }

-sudo_dso_public int
+ int
 setenv(const char *var, const char *val, int overwrite)
 {
     switch (process_hooks_setenv(var, val, overwrite)) {
@@ -266,9 +266,9 @@ unsetenv_unhooked(const char *var)
 }

 #ifdef UNSETENV_VOID
-sudo_dso_public void
+ void
 #else
-sudo_dso_public int
+ int
 #endif
 unsetenv(const char *var)
 {
diff --git a/src/sudo_noexec.c b/src/sudo_noexec.c
index c3e9cfb80..8495f613d 100644
--- a/src/sudo_noexec.c
+++ b/src/sudo_noexec.c
@@ -88,19 +88,19 @@ typedef struct interpose_s {
 }

 #define DUMMY1(fn, t1)              \
-sudo_dso_public int             \
+int                                 \
 FN_NAME(fn)(t1 a1)              \
 DUMMY_BODY                  \
 INTERPOSE(fn)

 #define DUMMY2(fn, t1, t2)          \
-sudo_dso_public int             \
+int                                 \
 FN_NAME(fn)(t1 a1, t2 a2)           \
 DUMMY_BODY                  \
 INTERPOSE(fn)

 #define DUMMY3(fn, t1, t2, t3)          \
-sudo_dso_public int             \
+int                                     \
 FN_NAME(fn)(t1 a1, t2 a2, t3 a3)        \
 DUMMY_BODY                  \
 INTERPOSE(fn)
@@ -112,7 +112,7 @@ DUMMY_BODY                   \
 INTERPOSE(fn)

 #define DUMMY_VA(fn, t1, t2)            \
-sudo_dso_public int             \
+int                                     \
 FN_NAME(fn)(t1 a1, t2 a2, ...)          \
 DUMMY_BODY                  \
 INTERPOSE(fn)
@@ -159,7 +159,7 @@ DUMMY6(posix_spawnp, pid_t *, const char *, const posix_spawn_file_actions_t *,
  */
 DUMMY1(system, const char *)

-sudo_dso_public FILE *
+FILE *
 FN_NAME(popen)(const char *c, const char *t)
 {
     errno = EACCES;
@@ -174,7 +174,7 @@ INTERPOSE(popen)
  */
 typedef int (*sudo_fn_wordexp_t)(const char *, wordexp_t *, int);

-sudo_dso_public int
+int
 FN_NAME(wordexp)(const char *words, wordexp_t *we, int flags)
 {
 #if defined(HAVE___INTERPOSE)

applied and it worked.

My understanding is that the compiler applies -Bhidden_def, but the headers files from /usr/include look like:

$ grep -r popen /usr/include/
/usr/include/stdio.h:#      pragma extern pclose, popen, tempnam
/usr/include/stdio.h:#    pragma HP_DEFINED_EXTERNAL pclose,popen,tempnam
/usr/include/stdio.h:#    pragma HP_NO_RELOCATION pclose,popen,tempnam
/usr/include/stdio.h:#    pragma HP_LONG_RETURN pclose,popen,tempnam
/usr/include/stdio.h:     extern __FILE *popen __((const char *, const char *));

$ grep -r execve /usr/include/
/usr/include/sys/scall_define.h:#define SYS_execve      59
/usr/include/sys/unistd.h:#pragma extern dup, dup2, execl, execle, execlp, execv, execve, execvp
/usr/include/sys/unistd.h:     extern int execve __((const char *, char *const [], char *const []));

$ grep -r putenv /usr/include/
/usr/include/sys/kern_svcs.h:extern int putenv __((const char *));
/usr/include/stdlib.h:#    pragma extern srand48, seed48, putenv
/usr/include/stdlib.h:#    pragma HP_DEFINED_EXTERNAL seed48,putenv
/usr/include/stdlib.h:#    pragma HP_NO_RELOCATION seed48,putenv
/usr/include/stdlib.h:#    pragma HP_LONG_RETURN seed48,putenv
/usr/include/stdlib.h:     extern int putenv __((const char *));
/usr/include/stdlib.h:     extern int putenv __((char *));

$ grep -r wordexp /usr/include/
/usr/include/wordexp.h:#  pragma extern wordexp, wordfree
/usr/include/wordexp.h:     extern int wordexp __(( const char * __restrict, wordexp_t * __restrict, int ));
/usr/include/wordexp.h:     extern void wordfree __(( wordexp_t * ));

I am not a fully fledged C hacker, but assume that the pragma extern explicit disallows declspec any kind. Reference documentation: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c05054285
I have also checked the same declarations on FreeBSD and no pragma extern is applied.
With my limited knowledge I see only one solution: introduce sudo_posix_dso_public which could handle standard redefinitions.

feature: sudo cd

As to me this is quite natural thing to have given that some directories can't be changed to beforehand due to theirs ownership and permission mode.

user added by systemd-homed won't be able to use sudo

user won't be able to use sudo, since this user doesn't exist in /etc/passwd, /etc/group, and /etc/shadow, it can be access by getent, sudo currently cannot use identify these users.

in container: sudo: setrlimit(RLIMIT_CORE): Operation not permitted

Apparently since version 1.8.29, sudo started outputting this warning in Linux rootless containers:

$ sudo hello > /dev/null
sudo: setrlimit(RLIMIT_CORE): Operation not permitted

which is quite annoying. This is with sudo-1.9.0b1.
(There are quite a lot of reports of this.)

Can something be done to alleviate it?

We can omit entering password using alias.

[slado122@slado122 ~]$ pacman -Syu
error: you cannot perform this operation unless you are root.
[slado122@slado122 ~]$ alias please="sudo"
[slado122@slado122 ~]$ please pacman -Syu

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do
[slado122@slado122 ~]$

It's a fresh session

sudo -u \#UID does not work in 1.9.5p2

We use docker container to build one of our components using alpine. Here is how to repro the scenario:

docker run -it --entrypoint sh alpine:3.10  
/ $ apk add --no-cache sudo
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing sudo (1.9.5p2-r0)
Executing busybox-1.30.1-r3.trigger
OK: 7 MiB in 15 packages
/ $ sudo -u \#4191700 ls
sudo: unknown user: #4191700
/ $ sudo --version
Sudo version 1.9.5p2

Now I can do the same thing in alpine 3.9 and it works fine.

docker run -it --entrypoint sh alpine:3.9
/ $ apk add --no-cache sudo
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
(1/1) Installing sudo (1.8.25_p1-r3)
Executing busybox-1.29.3-r10.trigger
OK: 7 MiB in 15 packages
/ $ sudo -u \#4191700 ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var
/ $ sudo --version
Sudo version 1.8.25p1

--ku flag

Add a --ku flag so that more dangerous commands require more effort to complete.
Expected usage

$> sudo --ku rm -rf /
Password:
Please solve this puzzle to complete this command:
+-----+-----+-----+
|5    |  8  |  4 9|
|     |5    |  3  |
|  6 7|3    |    1|
+-----+-----+-----+
|1 5  |     |     |
|     |2   8|     |
|     |     |  1 8|
+-----+-----+-----+
|7    |    4|1 5  |
|  3  |    2|     |
|4 9  |  5  |    3|
+-----+-----+-----+
input (x, y, val)> 0, 2, 8
+-----+-----+-----+
|5    |  8  |  4 9|
|8    |5    |  3  |
|  6 7|3    |    1|
+-----+-----+-----+
|1 5  |     |     |
|     |2   8|     |
|     |     |  1 8|
+-----+-----+-----+
|7    |    4|1 5  |
|  3  |    2|     |
|4 9  |  5  |    3|
+-----+-----+-----+
input (x, y, val)>

Not logging out after changing an user password

Test case :

Open terminal. Access administrators by sudo su, then type a current password.
Success, then logout by exit.
After entering current user, then change a password by passwd.
Then, access admin again by sudo su. Its success without type an user new password (not yet reaching a timeout)

This is the screenshot :

I think it can be a system vulnerabilities, and my idea is more safe to logout when password of current user has been changed.
I'm sorry if my english is bad. Thanks!

sudoedit -V print usage_excl() instead of (only) usage() or version

I'm not on the master version but I believe it will behave the same way.
Sudo version 1.8.21p2 packaged with my ubuntu
I also installed 1.9.6p1 from GitHub release, it behave the same way.
I check the master source code and couldn't find any fix for it.

sudoedit -V
sudoedit: Only one of the -e, -h, -i, -K, -l, -s, -v or -V options may be specified
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

same -v and for -l.

it should show the sudoedit usage only. sudoedit -V doesn't appear to be a valid sudoedit argument. (should it ?)

eg :

sudoedit -i
usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

on the current master :

sudo/src/parse_args.c

Line 515 in ce1f0da

usage_excl();

		case 'V':
		    if (mode && mode != MODE_VERSION)
			usage_excl();
		    mode = MODE_VERSION;
		    valid_flags = 0;
		    break;

Also :

sudo/src/parse_args.c

Line 263 in ce1f0da

mode = MODE_EDIT;

    if (strcmp(progname, "sudoedit") == 0) {
	mode = MODE_EDIT;
	sudo_settings[ARG_SUDOEDIT].value = "true";
	valid_flags = EDIT_VALID_FLAGS;
    }

What I believe is the source of the bug :

In "sudoedit", mode is set to mode = MODE_EDIT; but parse_args() doesn't check MODE_EDIT before printing usage_excl().

It's my first time reading the sudo source code. I only wanted to understand the CVE-2021-3156, sorry about the messy report and the lack of patch.

Permissions of groups reading in /etc/group line order

If I set

...
%admin ALL=(ALL) NOPASSWD:ALL
%sudo ALL=(ALL) ALL
...

in my /etc/sudoers
and in my /etc/group

...
sudo:x:1001:user
admin:x:1002:user
...

and if I try to run something with sudo, I will must to enter a password, because the sudo group higher in an order than admin group in /etc/group, however the admin group have a wider permissions than a sudo group have in a /etc/sudoers

Why the sudo read permissions of groups in order of lines in /etc/group before the first occuarance?
Why it does not use a most wide permission in /etc/sudoers?

sudo -n incorrectly ask for a password when using pam

Hi all,

First and foremost, apologies if this bug is known or if I missed a workaround. If so, just send me there, thanks in advance.

I'm trying to use pam ssh agent auth to allow users to be able to sudo without a password, granted they are using the proper identity. While this seems to be working in interactive mode, non interactive mode keep asking for a password when none is needed.

$ sudo -V
Sudo version 1.8.27
Sudoers policy plugin version 1.8.27
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.27
$ sudo -k whoami
root
$ sudo -nk whoami
sudo: a password is required

Unless I am missing something, this seems like a bug. Clearly, a password is NOT required, unless I somehow fubared the config - which is absolutely possible.

pam ssh agent is setup as the first item in /etc/pam.d/sudo:

auth sufficient pam_ssh_agent_auth.so file=/path/to/authorized/pubkeys

sudo_logsrvd: support I/O logging plugins

The sudo log server should support the same I/O logging plugin API as sudo. Running the plugin on the log server instead of the client is more secure since a local user cannot interfere with it . It should be possible to use a sudo I/O plugin without making changes to the plugin. Python-based I/O plugins should also be supported.

setrlimit message

os:mojave 10.15.1
sudo version

https://www.sudo.ws/sudo/dist/packages/macOS/10.15/sudo-1.8.29.mac1015.pkg

sudo -l
sudo: setrlimit(8): Invalid argument

display this message

if /usr/bin/sudo -l ,no message like this
sudo: setrlimit(8): Invalid argument

and can not use touch id

/etc/pam.d/sudo

auth optional pam_reattach.so
auth sufficient pam_tid.so

...........

the old can work

Misleading debug statement in src/limits.c

The debug statement logs the value of dumpflag instead of the actual value set: 0

sudo/src/limits.c

Lines 211 to 214 in 109a033

 if (prctl(PR_SET_DUMPABLE, 0, 0, 0, 0) == -1) { 

 sudo_debug_printf(SUDO_DEBUG_ERROR|SUDO_DEBUG_ERRNO, 

 "prctl(PR_SET_DUMPABLE, %d, 0, 0, 0)", dumpflag); 

 }

The debug statement should look something like:
sudo_debug_printf(SUDO_DEBUG_ERROR|SUDO_DEBUG_ERRNO, "prctl(PR_SET_DUMPABLE, 0, 0, 0, 0)");

Empty string tty and pam_access

Hello,

it might not be a real issue but I experienced the following:

I had wanted to set for a user which would run sudo through his own crontab a "from" field (as in perm:user:from) in pam_access module configuration file (/etc/security/access.conf for me) "finer" than LOCAL, i.e. go

from +:user:LOCAL
to +:user:sudo

sudo being the pam service name and assuming that no tty would be set in a cron context.

Looking at the code of both sudo and pam_access (plugins/sudoers/auth/pam.c) I saw it would not work as sudo would force a NULL tty to an empty string and then pam_item_set() PAM_TTY to it, which in turn pam_access would pam_item_get().

So basically pam_access would never fall back to the 'sudo' pam service name as a tty is set but at the same time an empty string can not be set as a from (as in perm:user:from) into access.conf

As a comparison,cronnie does set PAM_TTY to 'cron' enabling the admin to state something like
+:user:cron

Would you think this is something to be looked at ?
I know the code states:

    /*
     * Some PAM modules assume PAM_TTY is set and will misbehave (or crash)
     * if it is not.  Known offenders include pam_lastlog and pam_time.
     */

and I guess there are reasons I cannot think of for setting tty to "" when tty == NULL

Thanks for your help

--
Thomas HUMMEL

I/O plugin eats all input

Hi!

It looks like sudo is eating up all input when using a pseudo-tty triggered by usage of an I/O plugin. An easy way to reproduce with the default sudoers plugins is by setting Defaults log_input there. And then executing in bash something like:

$ while read -r x ; do sudo echo $x; done < <(echo -e "aaa\nbbb\nccc\n")
aaa

The first read eats «aaa», then sudo eats «bbb» and «ccc», which passes to the inner echo, which ignores it, then on the next loop iteration the read gets an EOF.

A partial workaround for a custom plugin is to disable itself by returning 0 in its open method, but then that makes it unable to use its close method too, which might be undesirable. I've skimmed over the code, and I don't think this is really generally fixable whenever there are logging methods in place? But it would be nice for this to work at least when all log methods are set to NULL, perhaps by only calling exec_pty (instead of exec_nopty) only when there's at least one log method set?

Are CVE-2019-19232 and CVE-2019-19234 considered vulnerabilities?

As packagers (see here) we were wondering about these two CVEs reported about sudo:

CVE-2019-19232 CVSSv3=7.5
CVE-2019-19234 CVSSv3=7.5

The debian post on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947225#5 claims that sudo-1.8.30 fixes the issues.

However, I cannot find the fix in the linked changelog, nor on SUDO_1_8_29...SUDO_1_8_30

Do you consider them vulnerabilities/issues and were they already, or will they be, fixed?

Thanks!

LD_PRELOAD is ignored by sudo

@millert wrote in #41 (comment):

As for libnss-wrapper, that relies on LD_PRELOAD which is ignored by the dynamic loader for set-user-ID programs like sudo. I don't think this is an issue with sudo itself.

Are there any alternatives to solve the use case described here:
A docker container which is run via docker run -u UID should somehow create a user on startup. Even the entrypoint script is run with that user and doesn't have root permissions. sudo relies on some system functionality to resolve the UID to a user name. How can this be provided?

"This incident will be reported" wording

Perhaps the wording of this could be improved (or removed all together).

-s option command string manipulation

The manpage for the -s option says:

     -s, --shell
                 Run the shell specified by the SHELL environment variable if it is set or the shell specified by the invoking user's password database entry.  If a command is specified, it is passed to the shell for execution via
                 the shell's -c option.  If no command is specified, an interactive shell is executed.  Note that most shells behave differently when a command is specified as compared to an interactive session; consult the shell's
                 manual for details.

So if my SHELL is bash, I expect $ sudo -s "whoami; whoami" to be the same as running bash -c "whoami; whoami" as the root user. But that doesn't work:

$ sudo -s "whoami; whoami"
/bin/bash: line 1: whoami; whoami: command not found

Of course

# bash -c "whoami; whoami"
root
root

works fine.

Could my sudo be misconfigured or compiled with a missing/incorrect option for this to work correctly?
Or is this a bug in sudo or its man page?
Or is it a bug in my understanding?

I'm using Sudo version 1.9.4p2 via Arch Linux.

No sudo upgrade after installation

Operating System: Mac OS High Sierra (10.13)
sudo version before upgrade: 1.8.29
sudo version expected after upgrade: 1.9.4

After installing sudo-1.9.4.mac1013.pkg and then sudo-logsrvd-1.9.4.mac1013.pkg and rebooting my computer, when I type sudo --version I still see sudo 1.8.29, but I get the following output:

sudo --version
sudo: setrlimit(8): Invalid argument
Sudo version 1.8.29
sudo: error in /etc/sudo.conf, line 16 while loading plugin "sudoers_audit"
sudo: unable to find symbol "sudoers_audit" in sudoers.so
sudo: fatal error, unable to load plugins

Heap corruption (I think freeing uninitialized memory?) with sssd plugin

Hello,

I've been going down a rabbithole trying to debug a crash in sudo. I'm not familiar with the code, but I'll try to give as much info as I can. I believe that sssd is returning an error, and sudo's error handler is handling it badly. I'm doing this on Fedora 32, and it only recently started failing. We rebuilt the system, reinstalled everything, and it still crashes. Here's what our nsswitch.conf file looks:

[root@dev .libs]# cat /etc/nsswitch.conf
passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files
sudoers:    sss files
[...]

The issue appears to be related to the sssd plugin. When sss is enabled there, sudo immediately crashes with a segfault:

[ron@dev sudo]$ sudo -l
Segmentation fault

If I do that from an older version, but same config, it correctly prints an error:

[root@dev sudo]# sudo -U chris -ll
sudo: error in /etc/sudo.conf, line 16 while loading plugin "sudoers_audit"
sudo: unknown plugin type 3 found in /usr/libexec/sudo/sudoers.so
sudo: fatal error, unable to load plugins

If I disable sss, it also works. I compiled master (607076d) and confirmed it still crashes:

[root@dev sudo]# git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
[root@dev sudo]# git rev-parse HEAD
607076d8a0b42688b63d5da52b54715730022586
[root@dev sudo]# make clean && ./configure --prefix=/usr --with-sssd && make -j10

[...compile compile compile...]

[root@dev sudo]# cd ~ron/sudo/src/.libs/; ./sudo -U chris -ll
Segmentation fault

I debugged it:

[root@dev .libs]# gdb --args ./sudo -U chris -ll
(gdb) run
Starting program: /home/ron/sudo/src/.libs/sudo -U chris -ll
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-4.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 762346]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e34aa0 in free () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install oddjob-mkhomedir-0.34.6-1.fc32.x86_64
(gdb) bt
#0  0x00007ffff7e34aa0 in free () from /lib64/libc.so.6
#1  0x00007ffff7fc6205 in sss_sudo_free_values (values=<optimized out>) at src/sss_client/sudo/sss_sudo.c:192
#2  sss_sudo_free_values (values=0x7fffffffe660) at src/sss_client/sudo/sss_sudo.c:183
#3  0x00007fffea15baaf in sss_rule_to_priv (rc_out=<synthetic pointer>, rule=0x5555555a2610, handle=0x55555558ff70) at ./sssd.c:336
#4  sss_to_sudoers (sss_result=0x5555555a25e0, handle=0x55555558ff70) at ./sssd.c:398
#5  sudo_sss_query (nss=<optimized out>, pw=<optimized out>) at ./sssd.c:684
#6  0x00007fffea14c860 in display_privs (snl=0x7fffea1b0540 <snl>, pw=0x555555592898, verbose=verbose@entry=true) at ./parse.c:753
#7  0x00007fffea156555 in sudoers_policy_main (argc=argc@entry=0, argv=argv@entry=0x7fffffffec08, pwflag=pwflag@entry=54, env_add=env_add@entry=0x0, verbose=verbose@entry=true, closure=closure@entry=0x0) at ./sudoers.c:560
#8  0x00007fffea14deb2 in sudoers_policy_list (argc=0, argv=0x7fffffffec08, verbose=16777216, list_user=0x7fffffffee3f "chris", errstr=0x7fffffffe998) at ./policy.c:1041
#9  0x000055555555aae1 in policy_list (envp=0x7fffffffec10, user=0x7fffffffee3f "chris", verbose=16777216, argv=0x7fffffffec08, argc=0) at ./sudo.c:1223
#10 main (argc=<optimized out>, argv=<optimized out>, envp=0x7fffffffec10) at ./sudo.c:262

Since it's a potential memory issue, I also checked with valgrind, which sees issues in approximately the same place as gdb (created a gist since it got pretty long):

https://gist.github.com/499832b190b762f6b33770e160c5db3d

Oddly, it doesn't crash with valgrind - maybe because it handles unintialized memory more gracefully?

Here is sudo_debug from running master: https://gist.github.com/0a04421c0cc2df538be2660d8a5882f2

And sudoers_debug from the same execution: https://gist.github.com/f82c4ae2d427d400d8958d6c3d1082d6

And finally, I did a git bisect and found the first crashing commit is 22105009d86a5c252cc3d4d187fb54ac18a6ec0f:

[root@dev .libs]# git checkout 88f9f2ba9a55b3654c829bee69c6dcd7b5feef4d

[compile]

[root@dev sudo]# cd ~ron/sudo/src/.libs/; ./sudo -U chris -ll
sudo: error in /etc/sudo.conf, line 16 while loading plugin "sudoers_audit"
sudo: unknown plugin type 3 found in /usr/libexec/sudo/sudoers.so
sudo: fatal error, unable to load plugins

[root@dev .libs]# git checkout 22105009d86a5c252cc3d4d187fb54ac18a6ec0f

[compile]

# cd ~ron/sudo/src/.libs/; ./sudo -U chris -ll
Segmentation fault

That's all the information I could hope to find. I really hope that's enough, but I'm totally willing to give you whatever additional information (including an account on the box where it's failing or its qcow2 file).

Thanks!

About the CVE-2021-3156

After I saw the CVE-2021-3156 and I knew that it was there since 2011. I was thinking if sudo needs a security layer or something to help prevent from future exploits like this.

I was thinking if it could be a good idea to add a service that masks the sudo executable from non-sudoers (make it cannot be executed '/usr/bin/sudo' -> bash: command not found / permission denied)

Anyways I am not an expert, feel free to close the issue if what I am talking about is not possible or it could cause more bug and vulnerabilities.

logsrv manpages are installed even if disabled at compile time

I have recompiled and installed sudo 1.9.2 into a new PREFIX:

export PREFIX=/opt/ports
export LIBDIR=$PREFIX/lib/hpux32
export CC=/opt/aCC/bin/aCC
export CXX=/opt/aCC/bin/aCC
export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
export CPPFLAGS="-I$PREFIX/include"
export LDFLAGS="-L$LIBDIR"
$CONFIGURE --sysconfdir=$PREFIX/etc --disable-root-sudo --disable-sasl --disable-pam-session \
  --with-env-editor --without-ldap --disable-shared-libutil --enable-static-sudoers \
  --disable-log-server --disable-log-client --enable-gss-krb5-ccache-name

But I still see:

+│   │   │   ├── [-rw-r--r-- root     root    ]  /opt/ports/share/man/man1m/sudo_logsrvd.1m
+│   │   │   ├── [-rw-r--r-- root     root    ]  /opt/ports/share/man/man4/sudo_logsrvd.conf.4
+│   │   │   └── [-rw-r--r-- root     root    ]  /opt/ports/share/man/man4/sudo_logsrv.proto.4

They should not be present when the option has been disabled.

Using hardcoded openldap version makes impossible an update for OpenLDAP 2.5

In the project's code, we have a hardcoded value:

sudo/etc/sudo.pp

Line 349 in b0a32fe

DEPENDS="${DEPENDS}${DEPENDS:+, }libldap-2.4-2"

We should use a library without a version so it becomes possible to update to the newest OpenLDAP version (2.5.X).

Steps to reproduce:

Download openldap 2.5:
https://koji.fedoraproject.org/koji/taskinfo?taskID=70077129 (it is a scratch build and it'll be removed in the future or I may improve it. Please, contact me for the newer version: [email protected])
sudo dnf install openldap-2.5.5-1compat.fc35.x86_64.rpm openldap-devel-2.5.5-1compat.fc35.x86_64.rpm

Expected results:

The package is successfully updated.

Actual results:

...
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync
DNF version: 4.7.0
Command: dnf install openldap-2.5.5-1compat.fc35.x86_64.rpm openldap-devel-2.5.5-1compat.fc35.x86_64.rpm -d 10 
Installroot: /
Releasever: rawhide
cachedir: /var/cache/dnf
Base command: install
Extra commands: ['install', 'openldap-2.5.5-1compat.fc35.x86_64.rpm', 'openldap-devel-2.5.5-1compat.fc35.x86_64.rpm', '-d', '10']
User-Agent: constructed: 'libdnf (Fedora 35; generic; Linux.x86_64)'
repo: using cache for: beaker-Fedora
beaker-Fedora: using metadata from Sun 13 Jun 2021 10:06:11 AM CEST.
repo: using cache for: beaker-Fedora-Everything
beaker-Fedora-Everything: using metadata from Sun 13 Jun 2021 10:06:11 AM CEST.
repo: using cache for: beaker-harness
beaker-harness: using metadata from Mon 19 Apr 2021 04:35:10 PM CEST.
repo: using cache for: beaker-tasks
beaker-tasks: using metadata from Mon 14 Jun 2021 11:12:30 AM CEST.
repo: using cache for: fedora-cisco-openh264
fedora-cisco-openh264: using metadata from Tue 23 Feb 2021 01:47:28 AM CET.
repo: using cache for: rawhide
rawhide: using metadata from Sun 13 Jun 2021 10:06:11 AM CEST.
repo: using cache for: rawhide-modular
rawhide-modular: using metadata from Sun 13 Jun 2021 09:54:23 AM CEST.
Last metadata expiration check: 3:14:41 ago on Mon 14 Jun 2021 12:40:10 PM CEST.
timer: sack setup: 3941 ms
--> Starting dependency resolution
--> Finished dependency resolution
timer: depsolve: 1175 ms

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/dnf/cli/main.py", line 130, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python3.10/site-packages/dnf/cli/main.py", line 166, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.10/site-packages/dnf/base.py", line 860, in resolve
    raise exc
dnf.exceptions.DepsolveError: 
 Problem: The operation would result in removing the following protected packages: sudo

Merge Multiple Sudoer files from disparate hosts

I have several hosts, each with their own sudoer file. I would like to merge all those sudoer files into one file so I can distribute a single file through a 3rd party configuration management tool. cvtsudoers does some conversion and could be used for this purpose.

NOPASSWD not working during ssh username contains colon

I am trying to execute some command via ssh or bash.bashrc, but a password prompt pop unexpected.

Steps to Repro:

Update service side sudo configuration sudo visudo

%admin ALL=(ALL) NOPASSWD:ALL

Regular login with ssh testuser@localhost 'sudo echo 777'

jika@JIKA-PC:/etc$ ssh testuser@localhost 'sudo echo 777'
testuser@localhost's password:

Only 1 password prompt for ssh user authentication. The sudo command executed without password. This is expected.

jika@JIKA-PC:/etc$ ssh -t testuser:12@localhost 'sudo echo 777'
testuser:12@localhost's password: 
[sudo] password for testuser:

The first password prompt is for ssh user authentication which is expected. But the second password prompt is unexpected since we have configued NOPASSWD.

selinux_restore_tty: use fgetfilecon_raw/fsetfilecon_raw

Sudo uses fgetfilecon() and fsetfilecon() in selinux_restore_tty()
It should probably use fgetfilecon_raw() and fsetfilecon_raw() instead.

If you use mcstrans (a daemon that translates SELinux contexts to human readable strings), and you run shutdown -h now from a sudo -r sysadm.role -s shell then systemd will kill mcstrans before the sudo shell process gets killed.

Sudo, i think, still has the translated version of the context (retrieved with fgetfilecon()) in cache and tries to restore the context of the tty using the human readable version of the context. Since mcstrans is no longer present, that context is invalid prompting:

12:39 < grift> Dec 11 12:36:20 perfevent audit: SELINUX_ERR op=setxattr 
               invalid_context="wheel.id:wheel.role:users.terminals.pty.pty_file:SystemLow"
12:39 < grift> Dec 11 12:36:20 perfevent audit[859]: AVC avc:  denied  { mac_admin } for  pid=859 comm="sudo" capability=33  
               scontext=wheel.id:wheel.role:sudo.wheel.subj:s0 tcontext=wheel.id:wheel.role:sudo.wheel.subj:s0 tclass=capability2 permissive=0

By using fgetfilecon_raw() and fsetfilecon_raw() sudo would be using the "raw" context to restore the tty. This "raw" context is valid when mcstrans has been terminated.

Wildcard permits more than often intended in argument lists

Users often expect glob-like behaviour from sudoers rules and are surprised when arguments don't behave that way. PR #10 adds regex matching to argument lists. The only work around I know of to prevent * matching other arguments adds complexity and is awkward and doesn't work well with path traversal, that requires a second negation, like so:

user ALL=ALL /bin/cat /var/log/*
user ALL=ALL !/bin/cat /var/log/* *
user ALL=ALL !/bin/cat /var/log/*..*

I feel overall that the problem would be lessened greatly with this patch.

This will close bug 578.

Please support a password of 500 characters

sudo kept telling me that "Sorry, try again" when I copied and pasted my password. Then I change my password to "Qwer1234^", it worked perfectly.

So I guess a password of 500 characters is just too long for sudo?

Avoid logging Passwords by matching password prompts

As a sudo administrator I want to avoid logging passwords in IOlogs so I don't have an end user's password

One way this could be accomplished is to provide a mechanism that allows me to write a regular expression that I can match a password prompt that can exclude the logging of text when that prompt is reached.

can be exploit with traitor

i tried traitor and i got sudo access. how to fix it?
here is output

$ ./traitor --exploit docker:writable-socket

[+] Assessing machine state...
[+] Checking for opportunities...
[+][docker:writable-socket] Docker socket at /var/run/docker.sock is writable!
[+][docker:writable-socket] Opportunity found, trying to exploit it...
[+][docker:writable-socket] Building malicious docker image...
[+][docker:writable-socket] Creating evil container...
[+][docker:writable-socket] Starting evil container...
[+][docker:writable-socket] Backdooring host at /usr/bin/NBmg3g-7nxApAf- from guest...
[+][docker:writable-socket] Checking permissions...
[+][docker:writable-socket] Starting root shell...
[+][docker:writable-socket] Removing backdoor from host...
[+][docker:writable-socket] Removing container...
[+][docker:writable-socket] Cleaning up image...
[+][docker:writable-socket] Dropping you into a shell...

sudo constantly asking for password with LDAP SSH user.

Hello,
I'm using Ubuntu 16.04, just upgraded sudo from version 1.8.16 to 1.9.5p2. When I SSH to server by LDAP account, I try to run some sudo command, the server require to input password constantly, I'm sure that I input a correct password, but in auth.log show I entered incorrect password.
Feb 2 10:28:05 sin-rcr01 sudo: AVN\ttdung : 3 incorrect password attempts ; TTY=pts/1 ; PWD=/home/AVN/ttdung ; USER=root ; COMMAND=/bin/su
This is sudo -V of sudo 1.9.5

Sudo version 1.9.5p2
Configure options:
Sudoers policy plugin version 1.9.5p2
Sudoers file grammar version 48

Sudoers path: /etc/sudoers
Authentication methods: 'passwd'
Syslog facility if syslog is being used for logging: authpriv
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Send mail if user authentication fails
Send mail if the user is not in sudoers
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 5.0 minutes
Password prompt timeout: 5.0 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: *** SECURITY information for %h ***
Incorrect password message: Sorry, try again.
Path to lecture status dir: /var/lib/sudo/lectured
Path to authentication timestamp dir: /run/sudo/ts
Default password prompt: Password:
Default user to run commands as: root
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Path to the editor for use by visudo: /usr/bin/vi
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File descriptors >= 3 will be closed before executing a command
Reset the environment to a default set of variables
Environment variables to check for safety:
        TZ
        TERM
        LINGUAS
        LC_*
        LANGUAGE
        LANG
        COLORTERM
Environment variables to remove:
        *=()*
        RUBYOPT
        RUBYLIB
        PYTHONUSERBASE
        PYTHONINSPECT
        PYTHONPATH
        PYTHONHOME
        TMPPREFIX
        ZDOTDIR
        READNULLCMD
        NULLCMD
        FPATH
        PERL5DB
        PERL5OPT
        PERL5LIB
        PERLLIB
        PERLIO_DEBUG
        JAVA_TOOL_OPTIONS
        SHELLOPTS
        BASHOPTS
        GLOBIGNORE
        PS4
        BASH_ENV
        ENV
        TERMCAP
        TERMPATH
        TERMINFO_DIRS
        TERMINFO
        _RLD*
        LD_*
        PATH_LOCALE
        NLSPATH
        HOSTALIASES
        RES_OPTIONS
        LOCALDOMAIN
        CDPATH
        IFS
Environment variables to preserve:
        XAUTHORIZATION
        XAUTHORITY
        PS2
        PS1
        PATH
        LS_COLORS
        KRB5CCNAME
        HOSTNAME
        DISPLAY
        COLORS
Locale to use while parsing sudoers: C
Directory in which to store input/output logs: /var/log/sudo-io
File in which to store the input/output log: %{seq}
Add an entry to the utmp/utmpx file when allocating a pty
PAM service name to use: sudo
PAM service name to use for login shells: sudo
Attempt to establish PAM credentials for the target user
Create a new PAM session for the command to run in
Perform PAM account validation management
Enable sudoers netgroup support
Check parent directories for writability when editing files with sudoedit
Allow commands to be run even if sudo cannot write to the audit log
Allow commands to be run even if sudo cannot write to the log file
Log entries larger than this value will be split into multiple syslog messages: 960
File mode to use for the I/O log files: 0600
Execute commands by file descriptor instead of by path: digest_only
Type of authentication timestamp record: tty
Ignore case when matching user names
Ignore case when matching group names
Log when a command is allowed by sudoers
Log when a command is denied by sudoers
Sudo log server timeout in seconds: 30
Enable SO_KEEPALIVE socket option on the socket connected to the logserver
Verify that the log server's certificate is valid
Set the pam remote user to the user running sudo
The format of logs to produce: sudo

Local IP address and netmask pairs:
        10.123.1.34/255.255.255.0
        fe80::46f:e4ff:fe8e:176/ffff:ffff:ffff:ffff::

Sudoers I/O plugin version 1.9.5p2
Sudoers audit plugin version 1.9.5p2

Here is output of sudo 1.8.16 before upgrading:

Sudo version 1.8.16
Configure options: --prefix=/usr -v --with-all-insults --with-pam --with-fqdn --with-logging=syslog --with-logfac=authpriv --with-env-editor --with-editor=/usr/bin/editor --with-exampledir=/usr/share/doc/sudo/examples --with-timeout=15 --with-password-timeout=0 --with-passprompt=[sudo] password for %p:  --without-lecture --with-tty-tickets --disable-root-mailer --enable-admin-flag --with-sendmail=/usr/sbin/sendmail --with-rundir=/var/run/sudo --mandir=/usr/share/man --libexecdir=/usr/lib/sudo --with-sssd --with-sssd-lib=/usr/lib/x86_64-linux-gnu --with-selinux --with-linux-audit
Sudoers policy plugin version 1.8.16
Sudoers file grammar version 45

Sudoers path: /etc/sudoers
Authentication methods: 'pam'
Syslog facility if syslog is being used for logging: authpriv
Syslog priority to use when user authenticates successfully: notice
Syslog priority to use when user authenticates unsuccessfully: alert
Send mail if user authentication fails
Send mail if the user is not in sudoers
Use a separate timestamp for each user/tty combo
Lecture user the first time they run sudo
Require users to authenticate by default
Root may run sudo
Allow some information gathering to give useful error messages
Require fully-qualified hostnames in the sudoers file
Visudo will honor the EDITOR environment variable
Set the LOGNAME and USER environment variables
Length at which to wrap log file lines (0 for no wrap): 80
Authentication timestamp timeout: 15.0 minutes
Password prompt timeout: 0.0 minutes
Number of tries to enter a password: 3
Umask to use or 0777 to use user's: 022
Path to mail program: /usr/sbin/sendmail
Flags for mail program: -t
Address to send mail to: root
Subject line for mail messages: *** SECURITY information for %h ***
Incorrect password message: Sorry, try again.
Path to lecture status dir: /var/lib/sudo/lectured
Path to authentication timestamp dir: /var/run/sudo/ts
Default password prompt: [sudo] password for %p:
Default user to run commands as: root
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Path to the editor for use by visudo: /usr/bin/editor
When to require a password for 'list' pseudocommand: any
When to require a password for 'verify' pseudocommand: all
File descriptors >= 3 will be closed before executing a command
Reset the environment to a default set of variables
Environment variables to check for sanity:
        TZ
        TERM
        LINGUAS
        LC_*
        LANGUAGE
        LANG
        COLORTERM
Environment variables to remove:
        __BASH_FUNC<*
        BASH_FUNC_*
        RUBYOPT
        RUBYLIB
        PYTHONUSERBASE
        PYTHONINSPECT
        PYTHONPATH
        PYTHONHOME
        TMPPREFIX
        ZDOTDIR
        READNULLCMD
        NULLCMD
        FPATH
        PERL5DB
        PERL5OPT
        PERL5LIB
        PERLLIB
        PERLIO_DEBUG
        JAVA_TOOL_OPTIONS
        SHELLOPTS
        BASHOPTS
        GLOBIGNORE
        PS4
        BASH_ENV
        ENV
        TERMCAP
        TERMPATH
        TERMINFO_DIRS
        TERMINFO
        _RLD*
        LD_*
        PATH_LOCALE
        NLSPATH
        HOSTALIASES
        RES_OPTIONS
        LOCALDOMAIN
        CDPATH
        IFS
Environment variables to preserve:
        XAUTHORIZATION
        XAUTHORITY
        PS2
        PS1
        PATH
        LS_COLORS
        KRB5CCNAME
        HOSTNAME
        HOME
        DISPLAY
        COLORS
Locale to use while parsing sudoers: C
Directory in which to store input/output logs: /var/log/sudo-io
File in which to store the input/output log: %{seq}
Add an entry to the utmp/utmpx file when allocating a pty
PAM service name to use
PAM service name to use for login shells
Attempt to establish PAM credentials for the target user
Create a new PAM session for the command to run in
Maximum I/O log sequence number: 0
Enable sudoers netgroup support
Check parent directories for writability when editing files with sudoedit

Local IP address and netmask pairs:
        10.124.1.237/255.255.255.0
        fe80::66:edff:feb1:3d80/ffff:ffff:ffff:ffff::

Sudoers I/O plugin version 1.8.16

I think the difference is "Authentication methods", the new version using "passwd" method instead of "pam", How can I change it?
Thanks.

sudoedit cannot write file with some editor

sudo 1.9.5

When I using nano as EDITOR, editor cannot write temporary file (created by sudoedit).

Error writing /var/tmp/hosts.XXWO1Dvy: Permission denied

License

Hi,

could you please add a LICENSE file to the repo? Thanks :)

macos catalina

hava macOS catalina version ?

and according this article

https://www.imore.com/how-use-sudo-your-mac-touch-id

the old version can work,and new version cann't work.

Integrating continuous fuzzing by way of OSS-Fuzz

Hi,

I would like to set up continuous fuzzing of Sudo by way of OSS-Fuzz. Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.

In this PR google/oss-fuzz#5052 I have done exactly that, namely created the necessary logic from an OSS-Fuzz perspective to integrate Sudo. If you would like to integrate, could you please provide a set of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. The emails should be linked to a Google account in order to view the detailed reports and notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.

I think there is a still a bit of way to creating really good fuzzers for Sudo, for example exit calls in iolog can be fairly annoying for the fuzzer as it will cause an in-memory fuzzer like libFuzzer to exit fast. I am happy to engage working on that if you are happy to integrate.

Let me know what you think

Change /var/log/sudo-io logging directory

Hello!

How can I change the default sudoreplay logging directory?
I could not find anything in the documentation and I am quite confused by the sudoreplay manual that mentions a command line flag to change that directory, is it only for reading the logs? Otherwise, nothing else I could find.

Thank you

Remove .sudo_as_admin_successful file from home folder.

Surely there must be some other way to check if the user is running sudo for the first time. Googling the file name as is, specificially ".sudo_as_admin_successful" will show the entire first page being devoted to removing the file. It is clear that many users find the file annoying and cluttering. Not to mention that it does not follow linux filesystem and XDG folder conventions.

Alternatively, default to not enabling the flag that creates the file

Missing manpage

Hello,

I'm trying to rebase sudo from 1.9.2 to 1.9.3p1 for fedora distro and file

/usr/share/man/man8/sudo_plugin_python.8.gz

seems to be gone.

Actually file is in the repo but it does not appear in the .rpm as it did with 1.9.2 tarball.

Add sudo to Homebrew?

Is there a reason why sudo is not available to install via Homebrew? It's available via MacPorts.

Possible bug: Unexpected prompting on sudo --list (-l) when no NOPASSWD lines specified

Using sudo -l shows some information about what commands be invoked. Usually this command is purely informative and will just give you the information you want.

However, if on your machine there are no NOPASSWD lines (e.g %users ALL=(root) NOPASSWD: /sbin/poweroff), then invoking sudo -l will prompt for a password and will not give you the information unless you provide a password.

I am unsure if that is a bug, but it is unexpected and has proven to cause a problem in an automated script that relied on this behavior. Homebrew/install#341

sudoers builds shared even if static is specified

Sudo: 1.9.5p2
Autoconf: 2.69

Issue:
Configuring with "--enable-static-sudoers" still results in sudoers.so

Reason:
SUDOERS_LDFLAGS is not populated correctly because of missing quotes for variable assignment in configure as a result of cb7e82a. This results in SUDOERS_LDFLAGS being empty, as can be seen in config.log
configure:26606: : SUDOERS_LDFLAGS="$SUDOERS_LDFLAGS"
SUDOERS_LDFLAGS=''

SUDOERS_LDFLAGS=--tag=disable-shared -static

Fix
SUDOERS_LDFLAGS="--tag=disable-shared -static"
https://github.com/sudo-project/sudo/blob/master/configure#L27486
https://github.com/sudo-project/sudo/blob/master/configure#L27532

	/* Scan str until we encounter white space. */
	for (cp = str; cp < endstr; cp++) {
	if (*cp == '\\') {
	/* quoted char, do not interpret */
	cp++;
	continue;
	}
	if (cp == ' ' \|\| cp == '\t') {
	/* end of word */
	break;
	}
	}
	*last = cp;

	if (prctl(PR_SET_DUMPABLE, 0, 0, 0, 0) == -1) {
	sudo_debug_printf(SUDO_DEBUG_ERROR\|SUDO_DEBUG_ERRNO,
	"prctl(PR_SET_DUMPABLE, %d, 0, 0, 0)", dumpflag);
	}

sudo-project / sudo Goto Github PK

sudo's Introduction

The sudo philosophy

Where to find sudo

What's new

Building the release

How to contribute

Copyright

Mailing lists

sudo-announce

sudo-blog

sudo-commits

sudo-users

sudo-workers

Sudo web page

Filing bug reports/issues

sudo's People

Contributors

Stargazers

Watchers

Forkers

sudo's Issues

Steps to Repro:

Recommend Projects

Recommend Topics

Recommend Org