From 8032533f26f0343e5a0ac07cfe2d31deb5d06b67 Mon Sep 17 00:00:00 2001 From: Badlop Date: Mon, 7 Jul 2008 14:52:47 +0000 Subject: [PATCH] * src/Makefile.in: Spool, config and log dirs: writtable by owner, readable by group, nothing by others (EJAB-686) * doc/guide.tex: New section Securing sensible files * doc/guide.html: Likewise SVN Revision: 1413 --- ChangeLog | 5 +++ doc/guide.html | 108 +++++++++++++++++++++++++++++------------------- doc/guide.tex | 35 ++++++++++++++-- src/Makefile.in | 6 ++- 4 files changed, 105 insertions(+), 49 deletions(-) diff --git a/ChangeLog b/ChangeLog index e06a1d381..6453c0987 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2008-07-07 Badlop + * src/Makefile.in: Spool, config and log dirs: writtable by owner, + readable by group, nothing by others (EJAB-686) + * doc/guide.tex: New section Securing sensible files + * doc/guide.html: Likewise + * doc/guide.tex: Solaris Makefile install: use ginstall (thanks to Jonathan Auer)(EJAB-649) * doc/guide.html: Likewise diff --git a/doc/guide.html b/doc/guide.html index 13fa36120..fa9fc7ae3 100644 --- a/doc/guide.html +++ b/doc/guide.html @@ -178,34 +178,35 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
  • 5.2  epmd
  • 5.3  Erlang Cookie
  • 5.4  Erlang node name +
  • 5.5  Securing sensible files
    • -
  • Chapter 6  Clustering +
  • Chapter 6  Clustering -
  • Chapter 7  Debugging +
  • Chapter 7  Debugging -
  • Appendix A  Internationalization and Localization -
  • Appendix B  Release Notes -
  • Appendix C  Acknowledgements -
  • Appendix D  Copyright Information +
  • Appendix A  Internationalization and Localization +
  • Appendix B  Release Notes +
  • Appendix C  Acknowledgements +
  • Appendix D  Copyright Information

    • Chapter 1  Introduction

    ejabberd is a free and open source instant messaging server written in Erlang.

    ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.

    ejabberd is designed to be a rock-solid and feature rich XMPP server.

    ejabberd is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.

    @@ -361,7 +362,7 @@ To get the full list run the command:
    /sbin/ejabberdctl
    Administration script
    /var/lib/ejabberd/
    - .erlang.cookie
    Erlang cookie file + .erlang.cookie
    Erlang cookie file (see section 5.3)
    db
    Mnesia database spool files
    ebin
    Binary Erlang files (*.beam)
    priv
    @@ -2966,7 +2967,7 @@ and you must login in the Jabber server with an account with proper privileges.

    4.4  Change Computer Hostname

    ejabberd uses the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, -so it stores the name of the Erlang node in it. +so it stores the name of the Erlang node in it (see section 5.4). The name of an Erlang node includes the hostname of the computer. So, the name of the Erlang node changes if you change the name of the machine in which ejabberd runs, @@ -3017,8 +3018,9 @@ You can limit the range of ports when starting Erlang with a command-line parame 

    erl ... -kernel inet_dist_listen_min 4370 inet_dist_listen_max 4375

    5.3  Erlang Cookie

    The Erlang cookie is a string with numbers and letters. -An Erlang node reads the cookie at startup from the command-line parameter -setcookie -or from a cookie file. +An Erlang node reads the cookie at startup from the command-line parameter -setcookie. +If not indicated, the cookie is read from the cookie file $HOME/.erlang.cookie. +If this file does not exist, it is created immediately with a random cookie. Two Erlang nodes communicate only if they have the same cookie. Setting a cookie on the Erlang node allows you to structure your Erlang network and define which nodes are allowed to connect to which.

    Thanks to Erlang cookies, you can prevent access to the Erlang node by mistake, @@ -3037,10 +3039,30 @@ to difficult unauthorized access to your Erlang node. However, it is not ultimately effective to prevent access to the Erlang node, because it may be possible to fake the fact that you are on another network using a modified version of Erlang epmd. -The recommended way to secure the Erlang node is to block the port 4369.

    -

    Chapter 6  Clustering

    +The recommended way to secure the Erlang node is to block the port 4369.

    +

    5.5  Securing sensible files

    ejabberd stores sensible data in the file system either in plain text or binary files. +The file system permissions should be set to only allow the proper user to read, +write and execute those files and directories.

    +ejabberd configuration file: /etc/ejabberd/ejabberd.cfg
    +Contains the JID of administrators +and passwords of external components. +The backup files probably contain also this information, +so it is preferable to secure the whole /etc/ejabberd/ directory. +
    ejabberd service log: /var/log/ejabberd/ejabberd.log
    +Contains IP addresses of clients. +If the loglevel is set to 5, it contains whole conversations and passwords. +If a logrotate system is used, there may be several log files with similar information, +so it is preferable to secure the whole /var/log/ejabberd/ directory. +
    Mnesia database spool files: /var/lib/ejabberd/db/*
    +The files store binary data, but some parts are still readable. +The files are generated by Mnesia and their permissions cannot be set directly, +so it is preferable to secure the whole /var/lib/ejabberd/db/ directory. +
    Erlang cookie file: /var/lib/ejabberd/.erlang.cookie
    +See section 5.3. +

    +

    Chapter 6  Clustering

    -

    6.1  How it Works

    +

    6.1  How it Works

    A Jabber domain is served by one or more ejabberd nodes. These nodes can be run on different machines that are connected via a network. They all must have the ability to connect to port 4369 of all another nodes, and must @@ -3054,29 +3076,29 @@ router,

  • session manager,
  • s2s manager.

    • -

    6.1.1  Router

    +

    6.1.1  Router

    This module is the main router of Jabber packets on each node. It routes them based on their destination’s domains. It uses a global routing table. The domain of the packet’s destination is searched in the routing table, and if it is found, the packet is routed to the appropriate process. If not, it is sent to the s2s manager.

    -

    6.1.2  Local Router

    +

    6.1.2  Local Router

    This module routes packets which have a destination domain equal to one of this server’s host names. If the destination JID has a non-empty user part, it is routed to the session manager, otherwise it is processed depending on its content.

    -

    6.1.3  Session Manager

    +

    6.1.3  Session Manager

    This module routes packets to local users. It looks up to which user resource a packet must be sent via a presence table. Then the packet is either routed to the appropriate c2s process, or stored in offline storage, or bounced back.

    -

    6.1.4  s2s Manager

    +

    6.1.4  s2s Manager

    This module routes packets to other Jabber servers. First, it checks if an opened s2s connection from the domain of the packet’s source to the domain of the packet’s destination exists. If that is the case, the s2s manager routes the packet to the process serving this connection, otherwise a new connection is opened.

    -

    6.2  Clustering Setup

    +

    6.2  Clustering Setup

    Suppose you already configured ejabberd on one machine named (first), and you need to setup another one to make an ejabberd cluster. Then do following steps:

    1. @@ -3110,10 +3132,10 @@ and ‘access’ options — they will be taken from enabled only on one machine in the cluster).

    You can repeat these steps for other machines supposed to serve this domain.

    -

    6.3  Service Load-Balancing

    +

    6.3  Service Load-Balancing

    -

    6.3.1  Components Load-Balancing

    -

    6.3.2  Domain Load-Balancing Algorithm

    +

    6.3.1  Components Load-Balancing

    +

    6.3.2  Domain Load-Balancing Algorithm

    ejabberd includes an algorithm to load balance the components that are plugged on an ejabberd cluster. It means that you can plug one or several instances of the same component on each ejabberd cluster and that the traffic will be automatically distributed.

    The default distribution algorithm try to deliver to a local instance of a component. If several local instances are available, one instance is chosen randomly. If no instance is available locally, one instance is chosen randomly among the remote component instances.

    If you need a different behaviour, you can change the load balancing behaviour with the option domain_balancing. The syntax of the option is the following:

    {domain_balancing, "component.example.com", <balancing_criterium>}.

    Several balancing criteria are available:

    • @@ -3122,13 +3144,13 @@ domain.

      -

      6.3.3  Load-Balancing Buckets

      +

      6.3.3  Load-Balancing Buckets

      When there is a risk of failure for a given component, domain balancing can cause service trouble. If one component is failing the service will not work correctly unless the sessions are rebalanced.

      In this case, it is best to limit the problem to the sessions handled by the failing component. This is what the domain_balancing_component_number option does, making the load balancing algorithm not dynamic, but sticky on a fix number of component instances.

      The syntax is the following: 

      {domain_balancing_component_number, "component.example.com", N}

      -

      Chapter 7  Debugging

      +

      Chapter 7  Debugging

      -

      7.1  Watchdog Alerts

      +

      7.1  Watchdog Alerts

      ejabberd includes a watchdog mechanism. If a process in the ejabberd server consumes too much memory, a message is sent to the Jabber accounts defined with the option @@ -3140,7 +3162,7 @@ Example configuration: To remove all watchdog admins, set the option with an empty list: 

      {watchdog_admins, []}.

      -

      7.2  Log Files

      An ejabberd node writes two log files: +

      7.2  Log Files

      An ejabberd node writes two log files:

      ejabberd.log
      is the ejabberd service log, with the messages reported by ejabberd code
      sasl.log
      is the Erlang/OTP system log, with the messages reported by Erlang/OTP using SASL (System Architecture Support Libraries) @@ -3157,12 +3179,12 @@ The possible levels are: For example, the default configuration is: 

      {loglevel, 4}.

      -

      7.3  Debug Console

      The Debug Console is an Erlang shell attached to an already running ejabberd server. +

      7.3  Debug Console

      The Debug Console is an Erlang shell attached to an already running ejabberd server. With this Erlang shell, an experienced administrator can perform complex tasks.

      This shell gives complete control over the ejabberd server, so it is important to use it with extremely care. There are some simple and safe examples in the article Interconnecting Erlang Nodes

      To exit the shell, close the window or press the keys: control+c control+c.

      -

      Appendix A  Internationalization and Localization

      +

      Appendix A  Internationalization and Localization

      All built-in modules support the xml:lang attribute inside IQ queries. Figure A.1, for example, shows the reply to the following query: 

      <iq id='5'
@@ -3189,9 +3211,9 @@ HTTP header ‘Accept-Language: ru’
 
 
 
        
      
-
      Appendix B  Release Notes
        
+
      Appendix B  Release Notes
        
 
      Release notes are available from ejabberd Home Page
        
      
-
      Appendix C  Acknowledgements
        
      Thanks to all people who contributed to this guide:
+
      Appendix C  Acknowledgements
        
      Thanks to all people who contributed to this guide:
 
        
      
-
      Appendix D  Copyright Information
        
      Ejabberd Installation and Operation Guide.
      
+
      Appendix D  Copyright Information
        
      Ejabberd Installation and Operation Guide.
      
 Copyright © 2003 — 2008 Process-one
      This document is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 as published by the Free Software Foundation; either version 2
diff --git a/doc/guide.tex b/doc/guide.tex
index d08fddbce..afd8b262f 100644
--- a/doc/guide.tex
+++ b/doc/guide.tex
@@ -361,7 +361,7 @@ The files and directories created are, by default:
 	\titem{/sbin/ejabberdctl} Administration script
 	\titem{/var/lib/ejabberd/}
 		\begin{description}
-			\titem{.erlang.cookie} Erlang cookie file
+			\titem{.erlang.cookie} Erlang cookie file (see section \ref{cookie})
 			\titem{db} Mnesia database spool files
 			\titem{ebin} Binary Erlang files (*.beam)
 			\titem{priv}
@@ -3652,7 +3652,7 @@ an account with proper privileges.
 
 \ejabberd{} uses the distributed Mnesia database. 
 Being distributed, Mnesia enforces consistency of its file,
-so it stores the name of the Erlang node in it.
+so it stores the name of the Erlang node in it (see section \ref{nodename}).
 The name of an Erlang node includes the hostname of the computer.
 So, the name of the Erlang node changes
 if you change the name of the machine in which \ejabberd{} runs,
@@ -3731,8 +3731,9 @@ erl ... -kernel inet_dist_listen_min 4370 inet_dist_listen_max 4375
 \makesection{cookie}{Erlang Cookie}
 
 The Erlang cookie is a string with numbers and letters. 
-An Erlang node reads the cookie at startup from the command-line parameter \term{-setcookie}
-or from a cookie file.
+An Erlang node reads the cookie at startup from the command-line parameter \term{-setcookie}.
+If not indicated, the cookie is read from the cookie file \term{\$HOME/.erlang.cookie}.
+If this file does not exist, it is created immediately with a random cookie.
 Two Erlang nodes communicate only if they have the same cookie.
 Setting a cookie on the Erlang node allows you to structure your Erlang network 
 and define which nodes are allowed to connect to which.
@@ -3764,6 +3765,32 @@ using a modified version of Erlang \term{epmd}.
 The recommended way to secure the Erlang node is to block the port 4369.
 
 
+\makesection{secure-files}{Securing sensible files}
+
+\ejabberd{} stores sensible data in the file system either in plain text or binary files.
+The file system permissions should be set to only allow the proper user to read,
+write and execute those files and directories.
+
+\begin{description}
+  \titem{ejabberd configuration file: /etc/ejabberd/ejabberd.cfg}
+  Contains the JID of administrators
+  and passwords of external components.
+  The backup files probably contain also this information,
+  so it is preferable to secure the whole \term{/etc/ejabberd/} directory.
+  \titem{ejabberd service log: /var/log/ejabberd/ejabberd.log}
+  Contains IP addresses of clients.
+  If the loglevel is set to 5, it contains whole conversations and passwords.
+  If a logrotate system is used, there may be several log files with similar information,
+  so it is preferable to secure the whole \term{/var/log/ejabberd/} directory.
+  \titem{Mnesia database spool files: /var/lib/ejabberd/db/*}
+  The files store binary data, but some parts are still readable.
+  The files are generated by Mnesia and their permissions cannot be set directly,
+  so it is preferable to secure the whole \term{/var/lib/ejabberd/db/} directory.
+  \titem{Erlang cookie file: /var/lib/ejabberd/.erlang.cookie}
+  See section \ref{cookie}.
+\end{description}
+
+
 \makechapter{clustering}{Clustering}
 \ind{clustering}
 
diff --git a/src/Makefile.in b/src/Makefile.in
index d3168165b..f3d81f65d 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -58,6 +58,7 @@ DESTDIR =
 
 EJABBERDDIR = $(DESTDIR)@localstatedir@/lib/ejabberd
 BEAMDIR = $(EJABBERDDIR)/ebin
+SPOOLDIR = $(EJABBERDDIR)/db
 PRIVDIR = $(EJABBERDDIR)/priv
 SODIR = $(PRIVDIR)/lib
 PBINDIR = $(PRIVDIR)/bin
@@ -107,20 +108,21 @@ install: all
 	install -m 644 *.beam $(BEAMDIR)
 	rm -f $(BEAMDIR)/configure.beam
 	install -m 644 *.app $(BEAMDIR)
+	install -d -m 750 $(SPOOLDIR)
 	install -d $(SODIR)
 	install -d $(PBINDIR)
 	install -m 644 *.so $(SODIR)
 	$(INSTALL_EPAM)
 	install -d $(MSGSDIR)
 	install -m 644 msgs/*.msg $(MSGSDIR)
-	install -d $(ETCDIR)
+	install -d -m 750 $(ETCDIR)
 	[ -f $(ETCDIR)/ejabberd.cfg ] && install -b -m 644 ejabberd.cfg.example $(ETCDIR)/ejabberd.cfg-new || install -b -m 644 ejabberd.cfg.example $(ETCDIR)/ejabberd.cfg
 	sed -e "s*@rootdir@*@prefix@*" ejabberdctl.template > ejabberdctl.example
 	[ -f $(ETCDIR)/ejabberdctl.cfg ] && install -b -m 644 ejabberdctl.cfg.example $(ETCDIR)/ejabberdctl.cfg-new || install -b -m 644 ejabberdctl.cfg.example $(ETCDIR)/ejabberdctl.cfg
 	install -b -m 644 inetrc $(ETCDIR)/inetrc
 	install -d $(SBINDIR)
 	install -m 755 ejabberdctl.example $(SBINDIR)/ejabberdctl
-	install -d $(LOGDIR)
+	install -d -m 750 $(LOGDIR)
 
 uninstall: uninstall-binary