rfc1196.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1196                         Finger                    December 1990


   in the user information output, or at worst be ignored.

2.5.5.  Vending machines

   Vending machines SHOULD respond to a {C} request with a list of all
   items currently available for purchase and possible consumption.
   Vending machines SHOULD respond to a {U}{C} request with a detailed
   count or list of the particular product or product slot.  Vending
   machines should NEVER NEVER EVER eat requests.  Or money.

3.  Security

3.1.  Implementation security

   Sound implementation of Finger is of the utmost importance.
   Implementations should be tested against various forms of attack.  In
   particular, an RUIP SHOULD protect itself against malformed inputs.
   Vendors providing Finger with the operating system or network
   software should subject their implementations to penetration testing.

   Finger is one of the avenues for direct penetration, as the Morris
   worm pointed out quite vividly.  Like Telnet, FTP and SMTP, Finger is
   one of the protocols at the security perimeter of a host.
   Accordingly, the soundness of the implementation is paramount.  The
   implementation should receive just as much security scrutiny during
   design, implementation, and testing as Telnet, FTP, or SMTP.

3.2.  RUIP security

   Warning!!  Finger discloses information about users; moreover, such
   information may be considered sensitive.  Security administrators
   should make explicit decisions about whether to run Finger and what
   information should be provided in responses.  One existing
   implementation provides the time the user last logged in, the time he
   last read mail, whether unread mail was waiting for him, and who the
   most recent unread mail was from!  This makes it possible to track
   conversations in progress and see where someone's attention was
   focused.  Sites that are information-security conscious should not
   run Finger without an explicit understanding of how much information
   it is giving away.

3.2.1.  {Q2} refusal

   For individual site security concerns, the system administrator
   SHOULD be given an option to individually turn on or off RUIP
   processing of {Q2}.  If RUIP processing of {Q2} is turned off, the
   RUIP MUST return a service refusal message of some sort.  "Finger
   forwarding service denied" is adequate.  The purpose of this is to



Zimmerman                                                       [Page 7]

RFC 1196                         Finger                    December 1990


   allow individual hosts to choose to not forward Finger requests, but
   if they do choose to, to do so consistently.

   Overall, there are few cases which would warrant processing of {Q2}
   at all, and they are far outweighed by the number of cases for
   refusing to process {Q2}.  In particular, be aware that if a machine
   is part of security perimeter (that is, it is a gateway from the
   outside world to some set of interior machines), then turning {Q2} on
   provides a path through that security perimeter.  Therefore, it is
   RECOMMENDED that the default of the {Q2} processing option be to
   refuse processing.  It certainly should not be enabled in gateway
   machines without careful consideration of the security implications.

3.2.2.  {C} refusal

   For individual site security concerns, the system administrator
   SHOULD be given an option to individually turn on or off RUIP
   acceptance of {C}.  If RUIP processing of {C} is turned off, the RUIP
   MUST return a service refusal message of some sort.  "Finger online
   user list denied" is adequate.  The purpose of this is to allow
   individual hosts to choose to not list the users currently online.

3.2.3.  Atomic discharge

   All implementations of Finger SHOULD allow individual system
   administrators to tailor what atoms of information are returned to a
   query.  For example:

      -    Administrator A should be allowed to specifically choose to
           return office location, office phone number, home phone
           number, and logged in/logout time.

      -    Administrator B should be allowed to specifically choose to
           return only office location, and office phone number.

      -    Administrator C should be allowed to specifically choose to
           return the minimum amount of required information, which is
           the person's full name.

3.2.4.  User information files

   Allowing an RUIP to return information out of a user-modifiable file
   should be seen as equivalent to allowing any information about your
   system to be freely distributed.  That is, it is potentially the same
   as turning on all specifiable options.  This information security
   breach can be done in a number of ways, some cleverly, others
   straightforwardly.  This should disturb the sleep of system
   administrators who wish to control the returned information.



Zimmerman                                                       [Page 8]

RFC 1196                         Finger                    December 1990


3.2.5.  Execution of user programs

   Allowing an RUIP to run a user program in response to a Finger query
   is potentially dangerous.  BE CAREFUL!! -- the RUIP MUST NOT allow
   system security to be compromised by that program.  Implementing this
   feature may be more trouble than it is worth, since there are always
   bugs in operating systems, which could be exploited via this type of
   mechanism.

3.2.6.  {U} ambiguity

   Be aware that a malicious user's clever and/or persistent use of this
   feature can result in a list of most of the usernames on a system.
   Refusal of {U} ambiguity should be considered in the same vein as
   refusal of {C} requests (see section 3.2.2).

3.2.7.  Audit trails

   Implementations SHOULD allow system administrators to log Finger
   queries.

3.3.  Client security

   It is expected that there will normally be some client program that
   the user runs to query the initial RUIP.  By default, this program
   SHOULD filter any unprintable data, leaving only printable 7-bit
   characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
   This is to protect against people playing with terminal escape codes,
   changing other peoples' X window names, or committing other dastardly
   or confusing deeds.  Two separate user options SHOULD be considered
   to modify this behavior, so that users may choose to view
   international or control characters:

      -    one to allow all characters less than ASCII 32

      -    another to allow all characters greater than ASCII 126

   For environments that live and breathe international data, the system
   administrator SHOULD be given a mechanism to enable the latter option
   by default for all users on a particular system.  This can be done
   via a global environment variable or similar mechanism.










Zimmerman                                                       [Page 9]

RFC 1196                         Finger                    December 1990


4.  Examples

4.1.  Example with a null command line ({C})

Site: elbereth.rutgers.edu
Command line: <CRLF>

Login       Name               TTY Idle    When            Office
rinehart Mark J. Rinehart      p0  1:11 Mon 12:15  019 Hill       x3166
greenfie Stephen J. Greenfiel  p1       Mon 15:46  542 Hill       x3074
rapatel  Rocky - Rakesh Patel  p3    4d Thu 00:58  028 Hill       x2287
pleasant Mel Pleasant          p4    3d Thu 21:32  019 Hill    908-932-
dphillip Dave Phillips         p5  021: Sun 18:24  265 Hill       x3792
dmk      David Katinsky        p6    2d Thu 14:11  028 Hill       x2492
cherniss Cary Cherniss         p7    5  Mon 15:42  127 Psychol    x2008
harnaga  Doug Harnaga          p8  2:01 Mon 10:15  055 Hill       x2351
brisco   Thomas P. Brisco      pe  2:09 Mon 13:37  h055           x2351
laidlaw  Angus Laidlaw         q0  1:55 Mon 11:26  E313C       648-5592
cje      Chris Jarocha-Ernst   q1    8  Mon 13:43  259 Hill       x2413

4.2.  Example with name specified ({U}{C})

Site: dimacs.rutgers.edu
Command line: pirmann<CRLF>

Login name: pirmann                     In real life: David Pirmann
Office: 016 Hill, x2443                 Home phone: [phone]
Directory: /dimacs/u1/pirmann           Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
                      Work Schedule, Summer 1990
                 Rutgers LCSR Operations, 908-932-2443

                        Monday       5pm - 12am
                        Tuesday      5pm - 12am
                        Wednesday    9am -  5pm
                        Thursday     9am -  5pm
                        Saturday     9am -  5pm

                           larf larf hoo hoo









Zimmerman                                                      [Page 10]

RFC 1196                         Finger                    December 1990


4.3.  Example with ambiguous name specified ({U}{C})

Site: elbereth.rutgers.edu
Command line: ron<CRLF>
Login name: spinner                     In real life: Ron Spinner
Office: Ops Cubby,    x2443             Home phone: [phone]
Directory: /u1/spinner                  Shell: /bin/tcsh
Last login Mon May  7 16:38 on ttyq7
Plan:
            ught i
          ca      n
        m           a
       '      ...     t
      I      .   .     i
             !         m
      !       !       e
       p       !pool
        l
         e
          H


Login name: surak                       In real life: Ron Surak
Office: 000 OMB Dou,    x9256
Directory: /u2/surak                    Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.

Login name: etter                       In real life: Ron Etter
Directory: /u2/etter                    Shell: /bin/tcsh
Never logged in.
No Plan.

4.4.  Example of query type {Q2} ({U}{H}{H}{C})

Site: dimacs.rutgers.edu
Command line: [e-mail]@pilot.njin.net<CRLF>

[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick                     In real life: Charles Hedrick
Office: 484 Hill, x3088
Directory: /math/u2/hedrick             Shell: /bin/tcsh
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.





Zimmerman                                                      [Page 11]

RFC 1196                         Finger                    December 1990


5.  Acknowledgments

   Thanks to everyone in the Internet Engineering Task Force for their
   comments.  Special thanks to Steve Crocker for his security
   recommendations and prose.

6.  Security Considerations

   Security issues are discussed in Section 3.

7.  Author's Address

   David Paul Zimmerman
   Center for Discrete Mathematics and
   Theoretical Computer Science
   Rutgers University
   P.O. Box 1179
   Piscataway, NJ 08855-1179

   Phone: [phone]

   EMail: [e-mail]





























Zimmerman                                                      [Page 12]