[sudo-workers] sudo 1.9.8b2 released

[Daniele Palumbo]

Todd,

I think that the concept of intercept the execve is really wonderful!

Is there a possibility to allow *only* dynamic executables?
Is there a possibility to allow *only* SECURE_PATH as execve?

Thank you very much!
Daniele
 

> Il giorno 19 ago 2021, alle ore 20:33, Todd C. Miller <Todd.Miller at sudo.ws> ha scritto:
> 
> Firmato Parte PGP
> The second beta release of sudo 1.9.8 is now available.
> 
> In addition to bug fixes, sudo 1.9.8 adds a new "intercept" mode
> that can be used to intercept the execve() system call in the command
> run by sudo and do a policy check on sub-commands before they are
> executed.  Intercept mode uses LD_PRELOAD and a socket pair to
> communicate with the main sudo process to perform the sudoers check.
> As such, there are some limitations.  See the sudoers man page for
> details.
> 
> Sudo 1.9.8 also includes a new sudoers setting, log_children, which
> works like intercept mode but only logs the command that was run
> and does not validate it against the sudoers file.
> 
> Source:
>    https://www.sudo.ws/dist/beta/sudo-1.9.8b2.tar.gz
>    ftp://ftp.sudo.ws/pub/sudo/beta/sudo-1.9.8b2.tar.gz
> 
> SHA256 checksum:
>    7786a204965dc1e04d117da3b9b9b3f73ca6296b41af2d344c74fe5e231bdc05
> 
> MD5 checksum:
>    d93e23e5aa9a78ad32072105feb44b9e
> 
> Binary packages:
>    https://www.sudo.ws/dist/beta/packages/index.html#binary
> 
> For a list of download mirror sites, see:
>    https://www.sudo.ws/download_mirrors.html
> 
> Sudo web site:
>    https://www.sudo.ws/
> 
> Sudo web site mirrors:
>    https://www.sudo.ws/mirrors.html
> 
> Major changes between sudo 1.9.8b2 and 1.9.8b1:
> 
> * Sudo will no longer permit a set-user-ID or set-group-ID program
>   to be run in intercept mode unless the new "intercept_allow_setid"
>   sudoers setting is enabled.
> 
> * The mksigname and mksiglist helper programs are now built with
>   the host compiler, not the target compiler, when cross-compiling.
>   Bug #989.
> 
> Major changes between sudo 1.9.8b1 and 1.9.7p2:
> 
> * It is now possible to transparently intercepting sub-commands
>   executed by the original command run via sudo.  Intercept support
>   is implemented using LD_PRELOAD (or the equivalent supported by
>   the system) and so has some limitations.  The two main limitations
>   are that only dynamic executables are supported and only the
>   execve() system call is currently intercepted.  Its main use
>   case is to support restricting privileged shells run via sudo.
> 
>   To support this, there is a new "intercept" Defaults setting and
>   an INTERCEPT command tag that can be used in sudoers.  For example:
> 
>    Cmnd_Alias SHELLS=/bin/bash, /bin/sh, /bin/csh, /bin/ksh, /bin/zsh
>    Defaults!SHELLS intercept
> 
>   would cause sudo to run the listed shells in intercept mode.
>   This can also be set on a per-rule basis.  For example:
> 
>    Cmnd_Alias SHELLS=/bin/bash, /bin/sh, /bin/csh, /bin/ksh, /bin/zsh
>    chuck ALL = INTERCEPT: SHELLS
> 
>   would only apply intercept mode to user "chuck" when running one
>   of the listed shells.
> 
> * The new "log_children" sudoers setting can be used to log commands
>   run in a privileged shell.  It uses the same mechanism as the
>   intercept support described above and has the same limitations.
> 
> * Support for logging sudo_logsrvd errors via syslog or to a file.
>   Previously, most sudo_logsrvd errors were only visible in the
>   debug log.
> 
> * Better diagnostics when there is a TLS certificate validation error.
> 
> * Using the "+=" or "-=" operators in a Defaults setting that takes
>   a string, not a list, now produces a warning from sudo and a
>   syntax error from inside visudo.
> 
> * Fixed a bug where the "iolog_mode" setting in sudoers and sudo_logsrvd
>   had no effect when creating I/O log parent directories if the I/O log
>   file name ended with the string "XXXXXX".
> 
> * Fixed a bug in the sudoers custom prompt code where the size
>   parameter that was passed to the strlcpy() function was incorrect.
>   No overflow was possible since the correct amount of memory was
>   already pre-allocated.
> 
>