[sudo-users] Issue with apt command after setting log_subcmd option in /etc/sudoers file

[ronan.bertinhugault at orange.com]

Hello everyone,
We are attempting in our environment to increase our capability to check the commands used by our people when connecting to a VM through SSH.
The targeted server is an Ubuntu 22.04 OS based.


#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults        use_pty
#Defaults       log_host, log_year
Defaults       log_input, log_output, log_subcmds
#Defaults       !/usr/bin/bash intercept

# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d



So far we didn't encounter any issues when managing several commands.
However when proceeding to a sudo apt update command we encounter the following error message:

HOST:~$ sudo apt update
sh: intercept port not set
sh: intercept port not set
sh: intercept port not set
sh: intercept port not set
sh: 1: id: Permission denied
sh: 1: [: -ne: unexpected operator
sh: intercept port not set
sh: intercept port not set
sh: intercept port not set
sh: intercept port not set
sh: 1: systemctl: Permission denied
Hit:1 http://REPO/ubuntu/mirror/packages.chef.io/repos/apt/stable bionic InRelease
Ign:2 http://REPO/ubuntu/mirror/artifactory.tech.orange/artifactory/debian-mirror-orange-product-devops Ubuntu InRelease
Hit:3 http://REPO/ubuntu/mirror/apt.releases.hashicorp.com jammy InRelease
Hit:4 http://REPO/ubuntu/mirror/archive.ubuntu.com/ubuntu jammy InRelease
Hit:5 http://REPO/ubuntu/mirror/archive.ubuntu.com/ubuntu jammy-security InRelease
Hit:6 http://REPO /ubuntu/mirror/archive.ubuntu.com/ubuntu jammy-updates InRelease
sh: intercept port not set
sh: 1: /usr/bin/test: Permission denied
sh: intercept port not set
sh: 1: /bin/echo: Permission denied
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success '/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null'
E: Sub-process returned an error code


If any of you can provide me some explanations of what could be missing as specific parameters or if some configuration elements do create conflicts, I would appreciate.

Before trying to reach you, I proceed on some search with consideration about the use of the intercept command but wasn't successful so far.
Indeed we attempt to use the intercept flag to prevent the locking of commands executed with bash but the results were not relevant.

Thank you for any help you may provide.

Have a good day.

Regards.

Ronan BERTIN-HUGAULT
Head of < Zero Trust Security > department
Digital Cloud Services
Orange/INNOV/IT-S/DCS/ZTS

Ronan.bertinhugault at orange.com<mailto:Ronan.bertinhugault at orange.com>