The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 [Cписок руководств | Печать]

Xsecurity ()
  • >> Xsecurity (5) ( Solaris man: Форматы файлов )
  • Xsecurity (7) ( Solaris man: Макропакеты и соглашения )
  • Xsecurity (7) ( Разные man: Макропакеты и соглашения )
         Xsecurity - X display access control
         X provides mechanism for implementing  many  access  control
         systems.   The  sample  implementation includes five mechan-
             Host Access                   Simple host-based access control.
             MIT-MAGIC-COOKIE-1            Shared plain-text "cookies".
             XDM-AUTHORIZATION-1           Secure DES based private-keys.
             SUN-DES-1                     Based on Sun's secure rpc system.
             MIT-KERBEROS-5                Kerberos Version 5 user-to-user.
         Host Access
              Any client on a host in the host access control list is
              allowed  access  to the X server.  This system can work
              reasonably well in an environment where everyone trusts
              everyone,  or when only a single person can log in to a
              given machine, and is easy to  use  when  the  list  of
              hosts  used  is  small.  This system does not work well
              when multiple people can log in to a single machine and
              mutual trust does not exist.  The list of allowed hosts
              is stored in the X server and can be changed  with  the
              xhost  command.   When using the more secure mechanisms
              listed below, the host list is normally  configured  to
              be the empty list, so that only authorized programs can
              connect to the display.
              When using MIT-MAGIC-COOKIE-1, the client sends  a  128
              bit  "cookie"  along with the connection setup informa-
              tion.  If the cookie presented by  the  client  matches
              one  that  the  X server has, the connection is allowed
              access.  The cookie is chosen so that  it  is  hard  to
              guess;  xdm  generates  such cookies automatically when
              this form of access control is used.  The  user's  copy
              of the cookie is usually stored in the .Xauthority file
              in the home directory, although the  environment  vari-
              able  XAUTHORITY  can  be  used to specify an alternate
              location.  Xdm automatically passes  a  cookie  to  the
              server  for  each  new  login  session,  and stores the
              cookie in the user file at login.
              The  cookie  is  transmitted  on  the  network  without
              encryption,  so  there  is nothing to prevent a network
              snooper from obtaining the data and using  it  to  gain
              access  to  the  X server.  This system is useful in an
              environment where many users are  running  applications
              on the same machine and want to avoid interference from
              each other, with the caveat that this control  is  only
              as  good as the access control to the physical network.
              In environments where network-level snooping is  diffi-
              cult, this system can work reasonably well.
              Sites in the United States can use a  DES-based  access
              control  mechanism  called  XDM-AUTHORIZATION-1.  It is
              similar in usage to MIT-MAGIC-COOKIE-1 in that a key is
              stored in the .Xauthority file and is shared with the X
              server.  However, this key consists of two parts - a 56
              bit  DES encryption key and 64 bits of random data used
              as the authenticator.
              When connecting to the X server, the  application  gen-
              erates  192  bits of data by combining the current time
              in seconds (since 00:00 1/1/1970  GMT)  along  with  48
              bits  of  "identifier".   For  TCP/IP  connections, the
              identifier is the address plus port number;  for  local
              connections  it is the process ID and 32 bits to form a
              unique id (in case multiple  connections  to  the  same
              server  are  made from a single process).  This 192 bit
              packet is then encrypted using the DES key and sent  to
              the  X server, which is able to verify if the requestor
              is authorized to connect by decrypting  with  the  same
              DES key and validating the authenticator and additional
              data.  This system is useful in many environments where
              host-based  access  control  is inappropriate and where
              network security cannot be ensured.
              Recent versions of SunOS (and some other systems)  have
              included a secure public key remote procedure call sys-
              tem.  This system is based on the notion of  a  network
              principal; a user name and NIS domain pair.  Using this
              system, the X server can securely discover  the  actual
              user  name  of  the  requesting  process.   It involves
              encrypting data with the X server's public key, and  so
              the  identity  of  the user who started the X server is
              needed for this; this identity is stored in  the  .Xau-
              thority  file.   By  extending  the  semantics of "host
              address" to include this notion of  network  principal,
              this form of access control is very easy to use.
              To allow access by a new user, use xhost.  For example,
                  xhost keith@
              adds "keith" from the NIS domain of the local  machine,
              and  "ruth"  in the "" NIS domain.  For keith or
              ruth to successfully connect to the display, they  must
              add the principal who started the server to their .Xau-
              thority file.  For example:
                  xauth add SUN-DES-1
              This system only works on machines which support Secure
              RPC,   and  only  for  users  which  have  set  up  the
              appropriate public/private key pairs on  their  system.
              See  the  Secure  RPC  documentation  for  details.  To
              access the display from a remote host, you may have  to
              do a keylogin on the remote host first.
              Kerberos  is  a  network-based  authentication   scheme
              developed  by  MIT for Project Athena.  It allows mutu-
              ally suspicious principals to authenticate  each  other
              as  long  as each trusts a third party, Kerberos.  Each
              principal has a secret key known only to  it  and  Ker-
              beros.   Principals  includes  servers,  such as an FTP
              server or X server, and human users, whose key is their
              password.   Users  gain  access  to services by getting
              Kerberos tickets for those  services  from  a  Kerberos
              server.   Since  the  X  server has no place to store a
              secret key, it shares keys with the user who  logs  in.
              X  authentication  thus uses the user-to-user scheme of
              Kerberos version 5.
              When you log in via xdm, xdm will use your password  to
              obtain  the  initial  Kerberos tickets.  xdm stores the
              tickets in  a  credentials  cache  file  and  sets  the
              environment  variable  KRB5CCNAME to point to the file.
              The credentials cache is  destroyed  when  the  session
              ends  to  reduce the chance of the tickets being stolen
              before they expire.
              Since Kerberos is a user-based authorization  protocol,
              like the SUN-DES-1 protocol, the owner of a display can
              enable and disable specific users, or Kerberos  princi-
              pals.   The  xhost  client is used to enable or disable
              authorization.  For example,
                  xhost krb5:judy
              adds "judy"  from  the  Kerberos  realm  of  the  local
              machine, and "gildea" from the "" realm.
         Except for Host Access control, each of these  systems  uses
         data  stored in the .Xauthority file to generate the correct
         authorization information to pass along to the X  server  at
         connection     setup.      MIT-MAGIC-COOKIE-1    and    XDM-
         AUTHORIZATION-1 store secret data in the file; so anyone who
         can  read  the  file  can gain access to the X server.  SUN-
         DES-1 stores only the identity of the principal who  started
         the  server (1.hostname@domain when the server is started by
         xdm), and so it is not useful to anyone  not  authorized  to
         connect to the server.
         Each entry in the .Xauthority file matches a certain connec-
         tion  family  (TCP/IP,  DECnet  or  local connections) and X
         display name (hostname plus display  number).   This  allows
         multiple  authorization  entries  for  different displays to
         share the same data file.  A special connection family (Fam-
         ilyWild,  value  65535)  causes  an  entry  to  match  every
         display, allowing the entry to be used for all  connections.
         Each  entry additionally contains the authorization name and
         whatever  private  authorization  data  is  needed  by  that
         authorization  type  to  generate the correct information at
         connection setup time.
         The xauth program manipulates the .Xauthority  file  format.
         It  understands the semantics of the connection families and
         address formats, displaying them in an  easy  to  understand
         format.    It  also  understands  that  SUN-DES-1  and  MIT-
         KERBEROS-5 use string values for the authorization data, and
         displays them appropriately.
         The X server (when running on a workstation) reads  authori-
         zation  information  from  a file name passed on the command
         line with the -auth option (see the  Xserver  manual  page).
         The  authorization  entries  in the file are used to control
         access to the server.  In each of the authorization  schemes
         listed above, the data needed by the server to initialize an
         authorization scheme is identical to the data needed by  the
         client  to  generate  the appropriate authorization informa-
         tion, so the same file can be used by both processes.   This
         is especially useful when xinit is used.
              This system uses 128 bits of data  shared  between  the
              user  and  the X server.  Any collection of bits can be
              used.  Xdm generates these keys using  a  cryptographi-
              cally secure pseudo random number generator, and so the
              key to the next session cannot  be  computed  from  the
              current session key.
              This system uses two pieces of information.  First,  64
              bits of random data, second a 56 bit DES encryption key
              (again, random data) stored in 8 bytes, the  last  byte
              of  which  is  ignored.  Xdm generates these keys using
              the same random number generator as is  used  for  MIT-
              This system needs a string representation of the  prin-
              cipal  which  identifies the associated X server.  This
              information is used to encrypt the  client's  authority
              information  when it is sent to the X server.  When xdm
              starts the X server, it uses the root principal for the
              machine  on  which  it  is  running (1.hostname@domain,
              e.g., "").   Put-
              ting the correct principal name in the .Xauthority file
              causes Xlib to generate the  appropriate  authorization
              information using the secure RPC library.
              Kerberos reads tickets from the cache pointed to by the
              KRB5CCNAME  environment  variable,  so does not use any
              data from the .Xauthority file.  An entry with no  data
              must still exist to tell clients that MIT-KERBEROS-5 is
              Unlike the .Xauthority file for clients, the  authority
              file  passed  by  xdm to a local X server (with ``-auth
              filename'', see xdm(1)) does contain the  name  of  the
              credentials cache, since the X server will not have the
              KRB5CCNAME environment variable set.  The data  of  the
              MIT-KERBEROS-5  entry is the credentials cache name and
              has the form ``UU:FILE:filename'',  where  filename  is
              the  name of the credentials cache file created by xdm.
              Note again that this form is not used by clients.
         X(1), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)

    Поиск по тексту MAN-ов: 

    Inferno Solutions
    Hosting by

    Закладки на сайте
    Проследить за страницей
    Created 1996-2023 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру