SINDES (Secure INformation DElivery System) is used to deliver sensitive files to a large number of machines. It relies on HTTPS and x509 certificates to achieve a reasonable security level.


The system is divided into different parts:

  • The web server: will handle HTTPS connections
  • The web application: will handle HTTPS requests
  • The intercative shell: interface between administrators and SINDES

Web server configuration

Installation of the SINDES-ca RPM will create a few configuration files:

  • sindes-ssl.conf is the web server configuration for the SINDES web application.
  • ca.config is the OpenSSL configuration file for all the Certificate Authority (CA) operations.
  • getcertificate.log4perl.conf is the configuration file for the Log::Log4perl perl module used for powerfull and flexible logging.
As the mod_ssl package (on which SINDES-ca depends) installs a ssl.conf file with a VirtalHost , you need to edit this file and remove/comment the VirtualHost . It is not possible to have more than one VirtualHost using SSL (SSL mecanism is used before the web server can know which VirtualHost the client is requesting). Another possibility is to force the SINDES VirtualHost to listen on a different port than the standard https (443).

Running bootstrap script

SINDES-ca installs a script whose main use is to bootstrap the system, but not only. It can be used for:

  • initialyzing some databases (certificates, ACLs and mapping between hosts and cluster)
  • cleaning the certificate database
  • creates a Certificate Authority, a webserver certificate and corresponding RPM for easy deployement.

You first need to run the sindes-bootstrap-ca command with the -a argument. This will:

  • create a private key + a public self signed certificate to be used by the CA
  • create a private key + a public certificate for the web server, signed by the newly created CA
  • build a RPM with the CA's certificate. This RPM is to be installed on all node client.
  • initialize ACL and MAP databases.
The process will ask for a password to encrypt the web server's private key on disk. This password will be asked at every restart of Apache.

There is no password for the CA private key because we need the ability to sign certificates automatically [FIXME studying how to do this with a password and f-e shared mem].


Configuration is centralised in a single file: /etc/sindes/sindesrc . Additional files are used for advanced logging features (these are defined in main configuration file).

Main configuration consists of different section and of multiple key/value pairs (INI file):

  • ACL
    • file : absolute file path or basename for the ACL file (or base file name) file(s), depending on the DBM type. SINDES uses SDBM, so it's basename.
  • MAP
    • file : absolute file path to the MAP dbm file (base file name, as SLC3's apache needs SDBM format which consist of 2 files).
  • CA
    • ca_path : absolute path to the CA root directory
    • crl_file : absolute file path to CRL. This must be consistent with Apache's configuration.
    • ca_config : absolute file path to CA config file
    • baseurl : base url to access the Oracle web interface
    • database : the database name
    • username : the username
    • password : the password
  • MISC
    • domain_regex : this is used when the need to remove the domain name from FQDN arises. Syntax is Perl regular expression.
    • tempdir : a temporary directory where user/group sindes have read/write access. Other users don't need and should not be granted access to it.
    • tempdir_cleanup : mainly used when debugging. If true (=1) then the temporary directories are removed when finished. Unless you know what you are doing, you want this.
    • csr_name : a filename template in mktemp style for CSR file.
    • crt_name : a filename template in mktemp style for CRT file.
    • openssl : absolute path the the openssl executable.
    • scripts_root : where all the scripts are located.
    • output_root : where all the sensitive files are located.
    • log4perlconf : configuration file for log4perl
  • CGI
    • log4perlconf : configuration file for log4perl (GetCertificate web application only)
    • revoke_on_duplicate : whether to revoke certificate when a duplicate request is received. Should be set to 1 for a more agressive policy, but use with care (see below).

Here's a sample configuration file :

file = /var/sindes/myacl

scripts_root = /home/sindes/scripts
output_root = /home/sindes/rfiles
log4perlconf = /etc/sindes/sindessh.log4perl.conf

baseurl =

database = cerndb1
username = cdbsql
password = mypassword

file = /var/sindes/

domain_regex = \.cern\.ch
tempdir = /home/sindes/tmp/
tempdir_cleanup = 0
csr_name = csr-XXXX
crt_name = crt-XXXX
openssl = /usr/bin/openssl
item_suffix = .tar.gz

log4perlconf = /etc/sindes/getcertificate.log4perl.conf

ca_path = /var/sindes/CA/ca
crl_file = /var/sindes/crl.pem
ca_config = /etc/sindes/ca.config

revoke_on_duplicate = 1

For the moment, this file comes with the SINDES-Shell-bin RPM but it should be shipped in a separate RPM as it is shared by various others parts.

Web application installation and configuration

You need to install the perl-SINDES-GetCertificate RPM. It only contains the SINDES::GetCertificate perl module. Configuration resides in /etc/sindes/sindesrc under the CGI section. Currently, the only setting specific to this module is its logging configuration. Behavior can be changed via other shared configuration items in the same file.

Shell installation and configuration

You need to install the perl-SINDES-Shell RPM. This will create [FIXME: in a near futur] a sindes user whose login shell will be SINDES::Shellng . Configuration is done in $HOME/.sindesrc or /etc/sindes/sindesrc . Specific settings are found in the SHELL section of the configuration file.

Information preparation

This is done in at least three steps:

  • Configuration in CDB
  • Installation of files on the server
  • Tell SINDES what to do

CDB profile

Each item to be transfered needs to be defined in node's profile. An item has a unique name but can be "overloaded" with the scope attribute. This way, you can have a "generic" item delivered to a whole cluster and have a more specific one delivered to a given node. For each item in a profile, you must define a method and a scope :

  • method is either file or script . The file method is the simplest one as you provide SINDES with a file that will be transfered as is to the client nodes. The script method is bit more complicated as data is to be created by a script.
  • scope defines from which level SINDES will start searching for this item when the node is requesting it. Possible scope are, by searching order :=node= , cluster and global . Defining a given scope does not imply the resulting file will be from this exact scope (it can be from a lower one). Preparation process tries to force the effective scope to be equal to the defined scope .

You also need to give the URL to be used when requesting files from the node in webserver .

Here's a sample SINDES CDB section:

"/software/components/sindes/active" = true;
"/software/components/sindes/webserver" = "";
"/software/components/sindes/items/passwd/method" = "script";
"/software/components/sindes/items/passwd/scope"  = "node'';
"/software/components/sindes/items/randomstuff" \
       = nlist("method", "file", "scope", "node");
"/software/components/sindes/all" = "passwd,randomstuff";
As far as pan and CDB are concerned, this data representation works fine. As SINDES needs to gather informations for a large number of nodes, it uses CDBSQL , which doesn't permit to iterate over a pan named list (nlist ). For this reason, a list in string representation is maintened in the profile (/all ) and can be handled with pan functions: add_item/remove_item . For the moment, these functions do not work as panc is waiting for a bug fix to be deployed.

Installing local files

Before uploading files or script, you must define the items in the corresponding profiles. A command line tool will take care of uploading items to the server (it comes with SINDES-tool RPM): sindes-upload-file :.
sindes-upload-file --file <filename> --itemname <itemname> 
                   --server <server> 
                   [--target <target>] [--scope <scope>] 
                   [--method <method>]

-s/--scope : where should your file/script be uploaded
-m/--method: what is it? file or script
-f/--file: tarball
-i/--itemname: item name
-S/--server: where SINDES server resides
-t/--target: target name (hostname or clustername)

file method

Before uploading a file, you must make sure it has the correct format. It must be a gziped tar file (tarball). As the content must only be understood by the deployement script, you are free to put anything inside. Usually, the deployement script will assume that for a component named "item", the tarball contains a directory "item" with files inside.

The transfer uses an scp wrapper

Sample item tarball:

$ tar tvf item5.tar.gz 
drwxr-xr-x x/x    0 2005-06-08 15:37:33 item5/
-rw-r--r-- x/x   20 2005-06-08 15:37:36 item5/item5

Correct examples:

$ sindes-upload-file -f item5.tar.gz -i item5 -S pcitfio124 -s global
If no error displayed, then you can proceed with more items or to prepare step.

$ sindes-upload-file -f item5.tar.gz -i item5 -S pcitfio124 -t lxdev -s cluster
If no error displayed, then you can proceed with more items or to prepare step.

Errors examples:
$ sindes-upload-file -f item5.tar.gz -i item2 -S pcitfio124 -t lxdev -s cluster
Sorry, you want to transfert a file but profiles says it should be a script at 
/usr/bin/sindessh line 208
lost connection
If no error displayed, then you can proceed with more items or to prepare step.

$ sindes-upload-file -f item5.tar.gz -i idontexist -S pcitfio124 -t lxdev -s cluster
Sorry, can't find item "idontexist" in cluster lxdev at /usr/bin/sindessh line 201
lost connection
If no error displayed, then you can proceed with more items or to prepare step.

script method

Uploading a script is similar to uploading a file. There is a difference in the data format: the data must be encapsulated in a tarball which root must contain an executable called 'run' (can be a shell script or anything else).

Sample script tarball:

$ tar tvf item2.tar.gz 
-rwxr-xr-x x/x   494 2005-06-08 15:36:25 run
Uploading examples:
$ sindes-upload-file -f item2.tar.gz -i item2 -S pcitfio124 -t lxdev \
                     -s cluster -m script
If no error displayed, then you can proceed with more items or to prepare step.

When run is called, SINDES provides it with some information that may be usefull:

  • -l <scope> : gives the targeted scope for the resulting file
  • -h <target> : gives the target's name
  • -d <output> : gives the path to a temporary directory where the script is to write files to be transfered to node(s).

Only the -d is mandatory, others can be silently ignored.

Administration shell

The shell is the only way of remotely managing the SINDES items. Basically, you can:

  • open a time window and grant a client to request a certificate
  • prepare and check that files to be distributed to clients are in correct place
  • handle the Certificate Authority (revoke certificates, list certificates,...)

The shell can only be used thought ssh. It can be used in interactive mode:

$ ssh sindes@sindesserver
SINDESsh  > 

or in non interactive mode:

$ ssh sindes@pcitfio124 "listitems -target lxdev06"
|           Name     Scope    Method          Hostname          Cluster   File Script|
|          item1    global    script               N/A      N/A: global   ABS.   ABS.|
|          item2   cluster    script               N/A            lxdev   ABS.   ABS.|
|          item3      node    script           lxdev06            lxdev   ABS.   ABS.|
|          item4    global      file               N/A      N/A: global   ABS.      -|
|          item5   cluster      file               N/A            lxdev   ABS.      -|
|          item6      node      file           lxdev06            lxdev     OK      -|


ACLs are used for certificate requests: a client can request a certificate within a given time-window and if it has the right to. The acl command can act on the list of client and change the values for the time-window and the request right.

The -length <length> and -grant (or -deny ) are used to change the time-window and request right when -set is specified. Time-window will always start "from now" and its length is specified in seconds. The request right can be seen as a boolean.

Both commands can act on a list of hostname or on all machines composing a cluster by the use of -target and -type .

It is also possible to display the current ACL with the -print command.


SINDESsh  > acl -set -length 3600 -grant -target lxdev06
Setting acl for 1 host(s)
SINDESsh  > acl -set -length 2600 -grant -target lxplus -type cluster
Setting acl for 53 host(s)
SINDESsh  > acl -print
|       hostname          TTL     Request Right|
|      lxplus070         2592               YES|
|      lxplus060         2592               YES|
|      lxplus071         2592               YES|
Finally, you can remove some ACL entries with the -remove command (works the same way -set works) or with the -clean command. Cleaning the ACL means to remove every entries with an expired time window and no right to request a certificate or even every time window expired entries (give the -clean command twice). See following example:
SINDESsh  > acl -print
|       hostname          TTL     Request Right|
|      lxplus070          EXP                NO|
|      lxplus060          EXP                NO|
|      lxplus071          EXP                NO|
|      lxplus061          EXP                NO|
|      lxplus072          EXP                NO|
SINDESsh  > acl -clean
[INFO] Cleaning softly ACL
SINDESsh  > acl -print
|       hostname          TTL     Request Right|
|                NO ACLS FOUND                 |


SINDESsh  > acl -print
|       hostname          TTL     Request Right|
|      lxplus070          EXP               YES|
|      lxplus060          EXP               YES|
|      lxplus071          EXP               YES|
SINDESsh  > acl -clean -clean
[INFO] Cleaning hardly ACL
SINDESsh  > acl -print
|       hostname          TTL     Request Right|
|                NO ACLS FOUND                 |


The cert command can be used for really simple Certificate Authority (CA) operations like revoking a certificate and listing certificates for a given host/cluster. The command -check is used for listing the certificates. It will display the number of valid certificates (it should always be 0 or 1) and the number of revoked certificates. -digest can be usefull when only a few entries have something interesting (at least a valid/revoked certificate). See the following example:
SINDESsh  > cert -check -target lxdev -type cluster
|       hostname         valid   revoked|
|        lxdev02          NONE      NONE|
|        lxdev03          NONE      NONE|
|        lxdev04          NONE      NONE|
|        lxdev05          NONE      NONE|
|        lxdev06          NONE         3|
|        lxdev07          NONE      NONE|
|        lxdev08          NONE      NONE|
|      opladev04          NONE      NONE|
SINDESsh  > cert -check -target lxdev -type cluster -digest
|       hostname         valid   revoked|
|        lxdev06          NONE         3|

You can also revoke certificates. The target definition is always the same (using -target and/or -type ).
SINDESsh  > cert -check -target lxplus072
|       hostname         valid   revoked|
|      lxplus072             1         6|
SINDESsh  > cert -revoke -target lxplus072
[INFO] All (1) certificate(s) revoked (lxplus072)
SINDESsh  > cert -check -target lxplus072
|       hostname         valid   revoked|
|      lxplus072          NONE         7|


This command simply list the items found for a given target. The listing includes information about every items: its name, scope, method and hostname/cluster when possible. It will also try to figure out if necessary files are present or not:

  • for file method, it will check if a tarball is present in the right location and if no upper scope file shadows it.
  • for script method, it will make the same checks as above but will also check for correct script.
Return codes for the status are:

  • ABS. when a something was not found.
  • SHAD. when an upper scopped file was found.
  • OK when everything seems fine.

SINDESsh  > listitems -target lxdev -type cluster
|           Name     Scope    Method          Hostname          Cluster   File Script|
|          item1    global    script               N/A      N/A: global   ABS.   ABS.|
|          item2   cluster    script               N/A            lxdev   ABS.   ABS.|
|          item3      node    script           lxdev06            lxdev   ABS.   ABS.|
|          item4    global      file               N/A      N/A: global   ABS.      -|
|          item5   cluster      file               N/A            lxdev   ABS.      -|
|          item6      node      file           lxdev06            lxdev     OK      -|


The prepare command is used to check if items with file method have been uploaded and will run the items' script for the script method. It will also update the mapping between the clients' hostnames and their respective clusters' names. As prepare usually means that you want to open a time-window, prepare can take care of this so it's not usefull to use acl . By default, prepare will open a 1hour time window and "grant" the clients to request a certificate, but this can be changed by using -length <length> , -updatemap (or -noupdatemap ) and -grant (or -nogrant ). The target specification is similar to others command (-target and/or -type ). Example:

SINDESsh  > prepare -target lxdev06
[OK] item1 [host:lxdev06 in cluster: lxdev from script] in item1.tar.gz
[OK] item2 [host:lxdev06 in cluster: lxdev from script] in lxdev/item2.tar.gz
[OK] item3 [host:lxdev06 in cluster: lxdev from script] in lxdev/lxdev06/item3.tar.gz
[OK] item4 [host:lxdev06 in cluster: lxdev from file] in global/item4.tar.gz
[OK] item5 [host:lxdev06 in cluster: lxdev from file] in lxdev/item5.tar.gz
[OK] item6 [host:lxdev06 in cluster: lxdev from file] in lxdev/lxdev06/item6.tar.gz
[SUMMARY] 6 item(s) processed successfully. Updating ACL/MAP if necessary
[INFO] Updating host map for lxdev06 with 1 hosts, mapped to lxdev
[INFO] Updating ACL lxdev06 with 1 hosts
SINDESsh  > prepare -target lxdev -type cluster -length 10
[OK] item1 [host:lxdev06 in cluster: lxdev from script] in item1.tar.gz
SINDESsh  > acl -pr -ta lxdev -ty cluster
|       hostname          TTL     Request Right|
|        lxdev02            3               YES|
|        lxdev03            3               YES|


remove can be usefull when you need to remove files/script from the server because of file/script shadowing. This command can be dangerous as it can't check whether you are doing something wrong or not. You must provide a target (if scope is not "global") and a scope along with an item name and a "method". Examples:
SINDESsh  > remove -item item1 -m script -s global
[INFO] 1 files removed for item1
SINDESsh  > remove -item testitem -target lxplus -type cluster
[INFO] 53 files removed for testitem out of 53

remove will take care of empty directories after some files/scripts are removed:
SINDESsh  > remove -target lxplus -type cluster -item testitem -method script
[INFO] 53 script(s) removed for testitem out of 53
[INFO] 24 empty directorie(s) removed


verbose is used mainly for debugging. This command can attach a probe to every perl Module in SINDES. With a single command, you can have the debug output of any module on the screen. With additional arguments you can change the output format (how to display lines, file, methods, date, message number, ...). As this mecanism relies on the Log::Log4perl perl module, you will benefit from all its possibilities, mainly the inheritance. If you attach a probe (aka logger/appender) to the root module (SINDES ), you will have all debugging messages. It is not possible for the moment to have output of only one module, you will always get all the output from the module's children. Here's an example where the debugging output of all SINDES::OpenSSL will be displayed:
SINDESsh  > verbose -m SINDES::OpenSSL -enable
[INFO] Linking SINDES::OpenSSL 's logger to screen ((added_screenlog_237))
SINDESsh  > cert -check -digest -target lxdev -type cluster
|       hostname         valid   revoked|
[DEBUG] Found a matching line for lxdev06 with valid:R and serial:02
[DEBUG] Found a matching line for lxdev06 with valid:R and serial:03
[DEBUG] Found a matching line for lxdev06 with valid:R and serial:04
|        lxdev06          NONE         3|

You can see that it is not very easy to read both output (normal and debug). Depending on the output type, you may find easier to read the debugging informations by changing the output format:

SINDESsh  > verbose -m SINDES::OpenSSL -format ">>>>>>>>>>>>>>>>> %m%n" -enable
[INFO] Linking SINDES::OpenSSL 's logger to screen ((added_screenlog_185))
SINDESsh  >  cert -check -digest -target lxdev -type cluster
|       hostname         valid   revoked|
>>>>>>>>>>>>>>>>> Found a matching line for lxdev06 with valid:R and serial:02
>>>>>>>>>>>>>>>>> Found a matching line for lxdev06 with valid:R and serial:03
>>>>>>>>>>>>>>>>> Found a matching line for lxdev06 with valid:R and serial:04
|        lxdev06          NONE         3|


The Apache web server needs a small database to map a hostname to it's corresponding cluster. This map is written from the admin shell only. Only when the prepare step is successful the map will be updated with correct mapping. Of course, deleting dangling entries is to be made by hand using map command. It can list and remove the mappings. The way to designate target is the same as for the other commands with -target and -type .

SINDESsh  > map -print
|       Hostname                Cluster|
|        lxdev09                  lxdev|
|        lxdev08                  lxdev|
|        lxdev02                  lxdev|
|        lxdev10                  lxdev|
SINDESsh  > map -remove -target lxdev09
Removed 1 mapping(s)
SINDESsh  > map -print -target lxdev09
|       Hostname                Cluster|
|                NONE                  |

Additional informations

Short command name

The shell can understand short command name when there is no conflict. For example, if both foobar and fobar exist:

  • Typing foo is equivalent to foobar
  • Typing fob is equivalent to fobar
This is true for command name (verbose , listitems , ...) and for command line argument (-target , -type , ...).


SINDESsh  > li -ta lxdev -ty cluster
|           Name           Scope         Method        Hostname         Cluster|
|          item1          global         script             N/A     N/A: global|
|          item2         cluster         script             N/A           lxdev|

Use of range for targets

As targets are usually hostnames with fixed prefix and unique number (lxplus001 , lxbatch002 , ...), it is possible to use a range specification: [$x$-$y$] where $x$ and $y$ are numbers and $x<y$. Example:
SINDESsh  > cert -check -target lxdev0[2-5]
|       hostname         valid   revoked|
|        lxdev02          NONE      NONE|
|        lxdev03          NONE      NONE|
|        lxdev04          NONE      NONE|
|        lxdev05          NONE      NONE|
You can use more than once this mecanism (foo[1-2]bar[3-4] will give foo1bar3 , foo1bar4 , foo2bar3 and foo2bar4 )

Non interctive mode

The shell can be used in a non interactive mode when commands are given through ssh command line:
$ ssh sindesb 'listitems -ta lxdev06'
As the perl module Term::Shell seems to behave strangely when ssh does not allocate a tty, maybe it will be usefull to use the -t to force the tty allocation (you may see some garbage from Term::Shell .

$ ssh -t sindesb 'listitems -ta lxdev06'

Client setup

Install SINDES-client , SINDES-ca-certificate-<bla> and ncm-sindes along with SINDES-script-<bla> .

During node's installation, node will request a certificate using the sindes-get-certificate script. Then, the ncm component will be able to use the resulting certificate and request items.

To be able to install the received items, node first to have installed the deployement scripts (SINDES-script-<bla> where <bla> is an item name) provided by the item provider.

Providing an item

First, you need to know if the sensitive information will come from a simple file or if it os to be generated by a script on the SINDES server.

Creating a file item

You must make a tarball with all files within a subdirectory with the same name as the item. For example, for an item called password by which you want to transfer the /etc/passwd file:
$ ls
$ ln -s . password
$ tar zcf password.tar.gz password/passwd

The file password.tar.gz is ready to be uploaded to server.

Creating a script item

This method is a bit more complicated. Files to be pulled by client are to be generated by a script on the server side. It can be usefull when you want someone to be able to prepare files for machines without giving them sensitive data. Scripts can't be downloaded from the SINDES server via SINDES(ie. you can't use scp to get something from the sindes account).

These scripts will get called with a given set of arguments:

  • -l : the targeted scope. Usually not usefull except when it is global . In this case, the target name is not relevant.
  • -h : the target name. This can be a clustername or a hostname.
  • -d : the output directory. Where files are to be placed.
The given directory is a temporary directory which content will be packed in a tarball conforming to the format given in the previous section (a single subdirectory named like the item).

Creating the deployement script

Before an item can be distributed, some scripts need to be installed on all client nodes. There must be one script per item. Each script will be given the tarball received from SINDES server in order to be installed. The script can do anything: this is very convenient, but also this is a big risk.

In principle, not so many people can deploy scripts.

As you need to create RPM for each of your script, you can use the SINDES-scripts CVS module, it will help you in this task. Here's an example where a script for the item password is created. The script will simply overwrite the /etc/passwd with the file shipped in the tarball:

$ cvs co SINDES-scripts
$ cd SINDES-scripts
$ mkdir password
$ cp Makefile.sample password/Makefile
<edit password/Makefile according to your item (name, description, ...)>
$ cat password/Makefile 

DESCRIPTION=handles /etc/passwd file


Next, you need to write the script that will be used by the client. The full path to the received tarball is the first and unique argument. Here's a possible script:


function cleanup
   rm -rf $1

if [ $# != 1 ]; then
   echo "Usage: $0 <filename>"
   exit 1

TEMP=`mktemp -d /var/tmp/SINDES-item-XXXXXX`
umask 0077
if [ $? != 0 ]; then
   echo "Cant make temp dir"
   exit 1


cd $TEMP
/bin/tar zxf $1
if [ $? != 0 ]; then
   echo "Couldnt extract file from $1"
   cleanup $TEMP
   exit 1

cp password/passwd /etc/passwd
if [ $? != 0 ]; then
   echo "Error when copying passwd file"
   cleanup $TEMP
   exit 1
   chmod 0600 /etc/passwd.sindes
   if [ $? != 0 ];then
      echo "Cant change permission on /etc/passwd.sindes"
      cleanup $TEMP
      exit 1

It's up to this script to take care of temporary directories and permissions:

  • use mktemp for random name instead of fixed name (even when the PID is involved).
  • set permission correctly using umask (usually 0077 as you don't want anyone else to be able to read what you are doing). Changing permission after creation is not good solution.
Then, you simply have to run make :

$ make
[SPEC] SINDES-script-password.spec
[SOURCE TAR] SINDES-script-password-0.1.tar.gz
[RPM] building RPMS
$ ls -l ` rpm --eval %_rpmdir`/noarch/SINDES-script-password-0.1-1.noarch.rpm
-rw-r--r--  1 x x 2000 2005-06-27 16:06 


It is important to understand how the system works to know its weaknesses. SINDES can help in achieving a better security level but users should follow somes rules. Basically, SINDES has three steps:

  • certificate issuing.
  • items configuration.
  • items transfers.

Certificate issuing

This is the weakest part of the system as there is no easy way to identify the client node. System will have to trust DNS records and use some simple rules to avoid some possible attacks.

Possible IP/MAC sppofing

If an attacker can spoof a to-be-installed-node 's IP/MAC, named testnode , then it can request a certificate and it will be correctly issued. The certificate will be able to access node specific informations, cluster wide informations and global informations as far as it still uses the testnode hostname with the correct IP address.

To reduce the impact of such a scenario SINDES uses two mecanisms:

  • the "time-window"
  • the "revoke on duplicate request"
The first one will simply reject any certificate request received outside a given time window: it is important to reduce as much a possible its size.

The second one will revoke any certificate issued if a duplicate request is receveived within the time window. In principle, if the time window is opened for a node, then this node will request a certificate and trigger the revocation of the malicious certificate previously issued for the attacker. Of course, the node must still be able to request the certificate within the time-window, but this should be spotted by the installation process failling.

Even when both mecanism work, the attacker can access information during a short period of time which depends on

  • the time when the duplicate request appears (malicious certificate is added to the certificate revocation list
  • the web server refresh rate for this list (usually 15 minutes

Items configuration and system access

As SINDES ' main goal is to restrict access to sensitive information, it is important to restrict access to the server. The sindes user account should be the only way of accessing it, or at least should be the only way for admins of interacting with it. As the CERN's CC is using kerberos authentication, it is easy to restrict this account access and trace from which account it is being used.

A root access to the server makes it possible to read all sensitive information, issue valid certificate and tamper all SINDES ' scripts (this makes useless any runtime checks). Web server is not possible without the certificate "pass phrase" and this is the only limitation.

Transfers between client node and server

If previous steps are considered ok (meaning you are pretty sure noone has interfeared in the process), then transfer between client and server is as secure as HTTPS can be. Deployement scripts will be run as the ncm-ncd 's user (most probably root).
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2005-07-12 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback