Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
XSECURITY(7)	       Miscellaneous Information Manual		  XSECURITY(7)

       Xsecurity - X display access control

       X provides mechanism for	implementing many access control systems.  The
       sample implementation includes five mechanisms:
	   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 mu-
	      tual 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	autho-
	      rized programs can connect to the	display.

	      When using  MIT-MAGIC-COOKIE-1,  the  client  sends  a  128  bit
	      "cookie"	along  with  the connection setup information.	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  automati-
	      cally 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 variable	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	appli-
	      cations 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 difficult, this system can work
	      reasonably well.

	      Sites who	compile	with DES support 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 .Xau-
	      thority 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 generates 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/IPv4 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  authentica-
	      tor and additional data.	This system is useful in many environ-
	      ments 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	system.	  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 in-
	      volves 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 .Xauthority file.   By  ex-
	      tending  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  suc-
	      cessfully	 connect  to  the display, they	must add the principal
	      who started the server to	their .Xauthority 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 mutually suspicious princi-
	      pals to authenticate each	other as long as each trusts  a	 third
	      party,  Kerberos.	 Each principal	has a secret key known only to
	      it and Kerberos.	Principals includes servers, such  as  an  FTP
	      server  or  X  server, and human users, whose key	is their pass-
	      word.  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 cre-
	      dentials 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  dis-
	      able  specific  users, or	Kerberos principals.  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  informa-
       tion  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 any-
       one  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
       (unix.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 connection	family
       (TCP/IP,	DECnet or local	connections) and X display name	(hostname plus
       display number).	 This allows multiple authorization entries  for  dif-
       ferent displays to share	the same data file.  A special connection fam-
       ily (FamilyWild,	value 65535) causes an entry to	match  every  display,
       allowing	 the  entry  to	be used	for all	connections.  Each entry addi-
       tionally	contains the authorization name	and  whatever  private	autho-
       rization	data is	needed by that authorization type to generate the cor-
       rect information	at connection setup time.

       The xauth program manipulates the .Xauthority file format.   It	under-
       stands  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 authoriza-
       tion data, and displays them appropriately.

       The X server (when running on a workstation) reads authorization	infor-
       mation  from  a file name passed	on the command line with the -auth op-
       tion (see the Xserver manual page).  The	authorization entries  in  the
       file  are  used to control access to the	server.	 In each of the	autho-
       rization	schemes	listed above, the data needed by the  server  to  ini-
       tialize	an authorization scheme	is identical to	the data needed	by the
       client to generate the appropriate authorization	 information,  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	gener-
	      ates these keys using a cryptographically	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-MAGIC-COOKIE-1.

	      This system needs	a string representation	of the principal 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  (
	      name@domain,   e.g.,  "").
	      Putting the correct  principal  name  in	the  .Xauthority  file
	      causes  Xlib  to generate	the appropriate	authorization informa-
	      tion using the secure RPC	library.

	      Kerberos reads tickets from the cache pointed to by the  KRB5CC-
	      NAME  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 available.

	      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(7), xdm(1), xauth(1), xhost(1), xinit(1), Xserver(1)

X Version 11			  Release 6.6			  XSECURITY(7)


Want to link to this manual page? Use this URL:

home | help