Bug#578601: wildcards in /etc/sudoers are not working after update
Ralf Gross
Version: 1.6.9p17-2+lenny1
Severity: important
We use the following sudo rule to grant a remote nagios host access via snmp to the command line of a RAID controller.
snmp ALL=NOPASSWD:/opt/areca/cli64*
I don't know if it's needed, but here's the related snmpd.conf line:
extend check_areca /opt/areca/check_areca.pl
and the sudo line in check_areca.pl:
[...]
my $areca_cli = '/opt/areca/cli64';
[...]
@output = `sudo $areca_cli vsf info`;
[...]
This worked fine with sudo version 1.6.8p12-4. After a system update yesterday, this stopped working and nagios reports an error.
Starting the nagios check from the remote host manually shows this:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for snmp:
Command: cli64 vsf info failed, 256, aborting!
and the according line in auth.log
Apr 21 08:48:47 VUMEM004 sudo: pam_unix(sudo:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=snmp
Removing the wildcard or downgrading to 1.6.8p12-4 resolves the problem.
One thing I don't yet understand: if I execute the same sudo command locally in a shell as user snmp on the host (not via snmp) I don't get the sudo error.
$ whoami
snmp
$ sudo /opt/areca/cli64 vsf info
# Name Raid# Level Capacity Ch/Id/Lun State
===============================================================================
1 ARC-1210-VOL#00 1 Raid6 4000.0GB 00/00/00 Normal
===============================================================================
GuiErrMsg<0x00>: Success.
I don't see the difference, in both cases the script is executed as user snmp.
Nethertheless, downgrading or removing the wildcard solves the problem, so I guess it has something to do with the update.
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages sudo depends on:
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii libpam-modules 1.0.1-5+lenny1 Pluggable Authentication Modules f
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
sudo recommends no packages.
sudo suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bdale Garbee
> Package: sudo
> Version: 1.6.9p17-2+lenny1
Where did you get this version? It's not one of mine.
It's possible that one of the fixes for priv escalation holes found in those
older versions of sudo might be causing the problem. I'd love to know
if 1.7.2p6-1 which I uploaded to unstable yesterday works for you or
not, it should back-port to lenny ok, but I haven't tried.
Bdale
Ralf Gross
> On Wed, 21 Apr 2010 09:07:30 +0200, Ralf Gross <ralf....@stz-softwaretechnik.com> wrote:
> > Package: sudo
> > Version: 1.6.9p17-2+lenny1
>
> Where did you get this version? It's not one of mine.
Simple lenny update, seems to be a security release.
$apt-cache policy sudo
sudo:
Installiert: 1.6.9p17-2+lenny1
Kandidat: 1.6.9p17-2+lenny1
Versions-Tabelle:
*** 1.6.9p17-2+lenny1 0
900 http://debian lenny/updates/main Packages
100 /var/lib/dpkg/status
1.6.9p17-2 0
900 http://debian lenny/main Packages
http://packages.debian.org/lenny/sudo
Paket: sudo (1.6.9p17-2+lenny1) [security]
2010
sudo (1.6.9p17-2+lenny1) stable-security; urgency=high
* Non-maintainer upload by the Security Team.
* Fixed CVE-2010-0426: verify path for the 'sudoedit' pseudo-command
(Closes: #570737)
* Fixed CVE-2010-0427: When changing the runas user, reset any aux runas
groups we have cached.
-- Giuseppe Iuculano <iucu...@debian.org> Tue, 02 Mar 2010 15:22:43 +0100
> It's possible that one of the fixes for priv escalation holes found in those
> older versions of sudo might be causing the problem. I'd love to know
> if 1.7.2p6-1 which I uploaded to unstable yesterday works for you or
> not, it should back-port to lenny ok, but I haven't tried.
Hm, this version is not available on out local mirror yet. Instead I tried
1.7.2p5-1 from sid, which could be installed without problem on lenny.
The problem seems to be solved with this version:
snmpget -v2c -t 60 -c xxxx -OvQ vumem004 'NET-SNMP-EXTEND-MIB::nsExtendOutputFull."check_areca"'
OK: Controller number: 1 Raid Number: 1 RAID level: Raid6 Capacity: 4000.0GB State: Normal
What does this mean for the lenny version of sudo? Is it a "broken" security update?
Ralf
Bdale Garbee
> Hm, this version is not available on out local mirror yet. Instead I tried
> 1.7.2p5-1 from sid, which could be installed without problem on lenny.
>
> The problem seems to be solved with this version:
Cool!
> What does this mean for the lenny version of sudo?
It certainly seems that there's a bug in the version in question.
Bdale
Christoph Berg
> > What does this mean for the lenny version of sudo?
>
> It certainly seems that there's a bug in the version in question.
We have the same problem in a customer installation.
root ALL=(ALL) ALL
hobbit ALL=(ALL) NOPASSWD: /usr/local/lib/bb-sudo/*
%adm ALL=(ALL) ALL
The problem was sudo -u postfix
/usr/local/lib/bb-sudo/postfix-queue-list as user hobbit.
I tried to debug it, and could track it down to that calling the
script with a tty present worked, while it didn't when called from a
daemon (say cron).
The same setup works flawlessly on most other lenny boxes. (The
sudoers file is not 100% identical, but as this monitoring check runs
on dozens of boxes, I am positive that there is a bug in sudo.)
On other boxes, the symptons are different, but adding a specific rule
for that script fixes it.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/