nv-l
[Top] [All Lists]

Re: Briefing:AIX snmpd fails set with error status 4

To: nv-l@lists.tivoli.com
Subject: Re: Briefing:AIX snmpd fails set with error status 4
From: "Leslie Clark" <lclark@us.ibm.com>
Date: Tue, 5 Dec 2000 15:37:46 -0500
Ok, everyone on AIX pay attention here. Our friend George has put together
an explanation of the snmp set problem with recent versions of AIX, and
what
to do about it. Read carefully, and act accordingly.  I believe questions
on this
issue should be directed to AIX support, not Netview support (and not me!)

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit


To:   Leslie Clark/Southfield/IBM@IBMUS
cc:
Subject:  Briefing:AIX snmpd fails set with error status 4



Leslie,

Feel free to put this out on the list, and enjoy!

George de Socio
Tivoli NetView for UNIX and NT Support Technical Lead


---------------------- Forwarded by George deSocio/Tivoli Systems on
12/04/2000 02:51 PM ---------------------------

Introduction:

This is a problem summary and status report on the issue of the AIX snmpd
daemon on a NetView MLM rejects NetView snmp set commands with return code:
error-status 4 (readOnly).   While this is the most frequent manifestation
of the issue, there could be non-MLM presentations as well.

Note the location of the presentation (where you see an error message) of
the error is not necessarily the location where the error is occurring, for
example, you see the messages informing you of the error in the
netmon.trace file, but the error is occurring on a remote MLM somewhere in
the network.  The remote MLM somewhere in the network is the target of the
solution below.


Problem summary:

The AIX 4.2 or 4.3 snmpd daemon rejects snmp set commands with error status
4 (readOnly) after fixes for AIX APARs IY08481 or IY04865 are installed.
(snmpd at bos.net.tcp.client.4.2.1.34+ or 4.3.3.10+).


Impact on NetView:

   Introduction:

   NetView MLM's workhorse engine is the daemon midmand.  The configuration
   processes of midmand are snmp-based.  That is, midmand maintains its own
   MIB data, wherein is kept most configuration information.  In the case
   of midmand, to be configured via snmp, means to be a so-called "smux"
   agent.  In essence a smux agent is a subordinate agent to the snmp
   master agent.  On AIX the master agent is the daemon snmpd.  All snmp
   requests are directed to the master agent, which will pass through
   requests for data that are maintained by any of its smux agents.  It is
   important to understand the smux agents are closely coupled with the
   master agent, that is, they co-reside.

NetView MLM depends on MIB data for its configuration and operation.
Smconfig and APM, as well as NetView's netmon daemon, update MLM's MIB
data, but are unaware of the new security restriction imposed by snmpd.
The impact on NetView is described in NetView for UNIX V6 APAR IY13601.
NetView for UNIX Level 2 opened [a PMR] against AIX to seek relief from the
snmpd security implementation.  In addition we asked for a technical
escalation.  In response, was a report of APAR IY12532 (explained below).
We have since asked AIX to go forward with a design change request to move
implementation of snmpd security into snmpd.conf.  The current status is
the design is being implemented.  The design change is to change the
default security to disabled, deprecate the -U option, and define a new
option, -S, for enablement of security in the snmpd.conf file at the user's
discretion.


Current Solution:

As of AIX 4.3 APAR IY12532, which is fixed in bos.net.tcp.client.4.3.3.21,
there is a solution.  None for AIX 4.2, nor will there be one.  This
solution changes snmpd to accept a parameter ( -U ) to turn off snmpd
security.

To implement the solution, first upgrade to bos.net.tcp.client.4.3.3.21 (or
later), i.e., install IY12532 fixes.  Note this could be a substantial
upgrade...

   As of bos.net.tcp.client.4.3.3.21, you can run the snmpd daemon in
   unsecure mode by giving it the "-U" parameter at startup.  (See below to
   make the change persistent.)    Run the following two commands:

                               stopsrc -s snmpd

                          startsrc -s snmpd -a "-U"


   Run the following command to update the System Resource Controller's
   entry for snmpd in the AIX ODM database.  Note this change is persistent
   .  But note that it is conceivable that a file system restore or a
   future change to AIX could overwrite the ODM entry, and inadvertently
   re-enable snmpd security.

                           chssys -s snmpd -a "-U"


   Then, run the following two commands to recycle the snmpd daemon.  The "
   -U" will be retrieved from the ODM.

                               stopsrc -s snmpd

                              startsrc -s snmpd

   To verify the System Resource Controller's ODM entry for snmpd, issue
   the following command:

                     odmget -q subsysname=snmpd SRCsubsys

   and look for the following stanza in the object:
                              cmdargs = "-U"


   Note you cannot prevent "startsrc" from retrieving the "-U" from the ODM
   (if it's there).  However, you can remove the "-U" from the ODM by the
   following command:
                            chssys -s snmpd -a ""



Background:

Sometime prior to February, 2000, [someone perceived] that there was a
security exposure with the snmpd daemon running on AIX supported levels
4.2.0 and 4.3.0.  Two AIX APARs were written:  IY08481 and IY04865
respectively, which basically report that non-root users can update MIB
data on an AIX system.

In response to the APARs, AIX snmp development implemented two changes.
One change to the snmpd daemon, and one change to the snmpinfo command so
that it would work with the changed snmpd.

The change to snmpd was to reject any set request that was not from a
client on a trusted port, i.e. less than 1024.  The change to snmpinfo was
to use a trusted port if the user was root.

   Explanation of trusted port:

   TCP/IP defines a trusted port as being one that has the number
   assignment of less than 1024.  Indeed, many well-known ports are
   assigned numbers in the range of 1 to 1023.  For example, the telnet
   service can almost always be found on TCP port 23,  and the snmp agent
   (which is a server application) service can usually be found on UDP port
   161.  When one application on one host wants to start a conversation
   with another application on the same or different host using TCP/IP
   sockets, the client application gets a random port assigned by the
   operating system for its side of the conversation.  The server port is
   usually well-known or pre-arranged, and often is also trusted.  The
   combination of a client IP address:port and a server IP address:port is
   an internet-wide unique entity, and together define a conversation.  A
   client application in AIX can request that a trusted port be assigned
   for a conversation it wants to set up.  Then, if the application is
   running as root, a port number less than 1024 will be assigned.  The
   server can interrogate the client port assignment and make decisions
   based on the client's port.  From RFC 1700: "There is the restriction
   that only "superuser" on BSD derived systems such as SunOS can bind to a
   port number that is less than 1024.  So programs have used this
   information in the past to identify whether or not the service they were
   talking to was started by the superuser on the remote system.  Making
   this assumption is dangerous because not all systems enforce this
   restriction."  (The latter sentence is partly the basis for the AIX
   enhancement request).

A corresponding change was made to the AIX command snmp client application,
snmpinfo.  If run by root, snmpinfo will request a trusted port, and be
able to successfully issue snmp set commands to an updated AIX snmpd
daemon.

Since then, APAR IY12532 was opened against AIX 4.3 to provide a way to
turn off the snmpd security if desired.  In a subsequent update to the
snmpd daemon, a startup parameter of -U can be used to turn off snmpd
security.  The disablement is implemented in bos.net.tcp.client.4.3.3.21.


Text of APAR IY08481:

PROBLEM SUMMARY:

If a local non-root user can obtain a copy of snmpinfo and
mib.defs files, it can change the value of MIB variables which
is supposed be changed only by root.

To recreate, first make snmpinfo executable by anyone and the
file /etc/mibs.def readable by anyone (or simply grab the grab
the snmp tools from UCD) then:

$ hostname
arioch.austin.ibm.com

$ snmpinfo -m set -c private 1.3.6.1.2.1.1.5.0="bleh"
1.3.6.1.2.1.1.5.0 = "bleh"

$ hostname
bleh

Even though snmpinfo and mibs.def are not readable by any user,
the files can be found elsewhere.

PROBLEM CONCLUSION:

in library file: src/tcpip/usr/lib/libsnmp/io.c, function
init_io(), we add one more parameter to the function argument.
This is a flag to indicate who is calling this routine.
 If flag is one, it indicates that snmpd server is calling it.
 We will leave the way as it is.
 If the flag is zero, it indicates that snmpinfo is calling it.
 We will then see if the request is from root or non-root user.
 If it's from root, we call routine bindresvport() to bind to
 a trusted port which is always going to be less than 1024.
 Otherwise, if it's a non root user, we use bind() routine to
 bind any port available which is always going to be bigger than
 1024.

In file src/tcpip/usr/sbin/snmpd/snmpd.c,
function do_operation(), when the request is set, we will check
the client request's port number to see if it's a root request
or a non root request. If it's non root set request we will set
the error to readOnly, then return.
If it's a root set request, we will continue the processing.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Briefing:AIX snmpd fails set with error status 4, Leslie Clark <=

Archive operated by Skills 1st Ltd

See also: The NetView Web