Token switching in the template configuration ------------------------------------------------- Sysmask comes with a template (default) configuration. This configuration has most of its protection disabled in order not to hit people with incompatible system setups. So besides serving as examples, the main role of the template configuration is to define ways for token switching. Note that except some kernel daemons, all the system processes are launched by init and its children, and init launches its children according to the definition of the file /etc/inittab. Therefore one has only to modify /etc/inittab to put tokens to the first children launched by init, and the whole running system must follow. There is no way for any process to escape the imposed sysmask token and its associated masks, unless volontarily removed by the configuration. To activate the default configuration, you should patch /etc/inittab, according to the patch inittab.patch in the sysmask package. This patch puts a system token "init" to the daemon launcher /etc/init.d/rc (or /etc/rc.d/rc or something else, according to the system setup), for runlevels 3,4,5. And a system token "tty" is also put to the tty managers of the system (/sbin/getty or /sbin/mingetty or something else), as well as "xdm" to the xdm launcher. Therefore "init", "tty" and "xdm" are the initial dispatching tokens. These tokens put practically no restrictions for themselves, except the "exec" mask that is used to dispatch new tokens for processes they execute. The token dispatching rules are defined in the "exec" file of the two tokens. This dispatching is very simple for "tty" and "xdm", because it only has to tell which user logging in from the console should get what token. Of course you should edit the "exec" file to fit your system's needs. Initially, available tokens to switch people to are "none", "consoleuser", "xuser", "rootable", "fullroot", "developer", "nonet", "guest" (some of them have empty token definition to start with), but you may add more tokens of your own. Note that the xdm token comes empty in the package. This is because I don't use it personally, so I didn't bother defining it. The case for "init" is a bit more complicated. Please refer to the "exec" file: each daemon is recognized by the pathname of the executable, and a new token is attributed to each. The list is far from complete for the time being. Now some tokens within the list are themselves token dispatchers: it is the case for xinetd (not yet defined), and sshd whose dispatching rule should be defined in a similar way as for "tty" and "xdm". For people who cannot set up a firewall allowing only strictly limited access to sshd, the use of the quarantine zone can be considered for sshd. In this case, it is the quarantine zone that will dispatch user tokens, according to customized authentication rules defined in the quarantine token. The apache daemon can also be made to switch tokens, when cgi's are executed. The default configuration contains only two token switches, one for wims, the other for any other cgi. If you want to attribute different access rights according to the user on which the cgi depends, you can add more blocks to the "exec" file. The same is true for ftp daemon (for user ftp spaces) and mail daemon (for users' .forward files). Note that now you can use sysmask to define an anonymous ftp zone that is really secure. However, no ftpd token is defined in the default configuration, again because I don't use ftpd personally: with httpd available, anonymous ftp is redundant.