Daemon Processes

Introduction.

The most secretive, yet most productive, application or
service on a Unix system is the daemon process. A daemon,
pronounced 'demon,' process is secretive because it runs
in the background, and often does not indicate its presence
in any significant way. Without it, most Unix systems
would cease to function. Programmers write daemons to carry
out a function with little or no intervention by users
or system administrators. In fact, many daemons require
no intervention at all!

The services offered by daemon processes are important to
understand because the potential security violation may
occur through a program that masquerades as a daemon.

What is a daemon?

A daemon process is a process that is not associated with a user,
but performs system-wide functions, such as administration and
control, network services, execution of time-dependent activities,
and print services. For a process to qualify as a daemon process, several criteria
must be met: the process must not be associated with a user's
terminal session and it must continue after the user logs off.

From the rudimentary process management knowledge you have read
about so far, you know that each process a user starts is terminated
by the init program when the user exits. The init program is the most
famous of all system daemons. This approach allows for proper
management of the process table.

Although daemon processes are almost completely invisible, they do
provide some level of service to users. Daemon processes accept user
requests and process them; they also respond to various events and
conditions. They are often inactive, however, and are designed to be
called into service only when required. By using a daemon instead of
starting a new process for every instance, system load is reduced,
and large programs that take time to get started will not slow down
the user or the operation.

A daemon can be distinguished from other programs on the system
by examining the process table--the ps command displays this table.
The distinguishing characteristic of a daemon is that the TTY column
does not reflect the controlling terminal name.

The daemon is the process with a questions mark "?" as the controlling
terminal name. The controlling terminal is identified in the "TT" or "TTY"
column of the ps output. Whenever this is found in a process entry,
the process is a daemon.

Daemon processes usually do not accumulate very much CPU in the
short run, unless they have a lot of processing to do when they start.
It usually takes a tremendous amount of time for these daemons
processes to equal the CPU requirements that many other processes
accumulate in a minute or two.

The daemon processes shown in the ps output were likely started
as part of the system's boot process.

It is important to consider that the startup procedures of the various
Unix flavors often are very different depending upon the heritage.
SunOS 4.1.x, for example, is derived from the Berkeley Software
Distribution (BSD) code and as such bears little or no resemblance
to the startup procedure seen in Solaris 2.x, which is based upon
the Unix System Laboratories Unix System V Release 4.

The same is true when comparing Unix System V Release 3.2 and 4.0.
These differences are important to note, because they make it easier
to hide inconspicuous programs for later action.

The HP-UX startup sequence makes use of a large number of files,
each of which are tightly linked to a given subsystem. For example,
the file netlinkrc is used to start network processes. With this type
of startup file layout, it is much harder to locate the daemons and
to modify the system startup procedure.

Regardless of the Unix implementation being considered, the use of
the /etc/rc/ file start the system is common. Consider the list of
files required to start the daemons on an SCO OpenServer 5.0 system.

SCO Unix products use a file system structure that is grouped by the
desired run level. Run levels, their meanings, and how to switch between
them.

Like the HP-UX implementation, a number of SCO Unix startup scripts
are used to start daemons. Each script is essentially dedicated to
starting the daemons for a specific function group. This is not
necessarily bad design, but it requires a detailed level of understanding
of the underlying system structure.

Examining the System Daemons.

A number of system daemons can exist in a Unix system. Some are
only found in a specific version of Unix, but many daemons are common
to all versions of Unix. This section discusses many of the common
daemons and describes their function on the system.

init

The init daemon is known as the parent process for all the processes
on the system. It performs a broad range of functions that are vital to
the operation of a Unix system.

The most commonly known purpose of the init process is to boot the
system. The method init uses to boot the system differs among Unix
versions. The BSD and XENIX init programs, for example, do not work
the same way as the System V implementation. The System V init
program relies on the file /etc/inittab/ to provide details of how init is
supposed to govern the startup and initialization of the various services on the system.
The init process is commonly known as "init" because of its role in the
initialization of various processes during system operation.

The init program considers the system to be in a run level at any given
time. Run levels are the operating states of the system. For the purposes
of this section, a run level can be viewed as a software configuration;
each configuration allows only a selected group of processes to exit.

swapper

Some Unix system administrators refer to swapper as a daemon, and
others do not. The swapper process is responsible for scheduling the
use of memory by the various processes on the system. The swapper
process is actually part of the kernel, so you could say that it is not
a daemon after all.

update and bdflush

Update and bdflush are similar commands that periodically execute
the sync system call to flush disk buffers. These daemons execute
every 30 seconds. Users and system administrators rely on these
daemons to update the file system in case of a crash. Although two
commands are listed, your system will see one or the other, but rarely
both.

lpd

The lpd daemon is part of the BSD print services. It listens for and
accepts connections via TCP/IP to submit a print request. The lpd
daemon relies on the LPD protocol to accept the job, and submit it
to the requested printer. This daemon was almost exclusively found
on BSD-based systems until the more popular System V derivatives
started adding similar services.

lpsched

The lpsched daemon is the System V version of the print spooler. It
performs the same tasks as the BSD lpd program, but in a much different
format. Despite lpsched's inability to communicate directly via the LPD
protocol, it is still considered stronger than lpd because of its flexibility
with printer interface scripts.

cpd and sco_cpd

The cpd and sco_cpd daemons are the license managers for SCO products.
They are similar to license managers on other implementations of Unix in
that they ensure that all products on the local network have unique
serial numbers. With the release of SCO OpenServer 5.0, the license
managers support shrink-wrapped software and operating system software.

cron

The cron daemon is the automated task scheduler; it runs scheduled jobs
at the requested time. A user may want to execute a number of jobs at
regular intervals, for example. To do this, a crontab file is created resembling
the following:

0,15,30,45 * * * * /usr/stats/bin/getstats border1.ottowa
0 3 * * 0 /usr/stats/bin/merge border1.ottawa
0 4 * * 0 /usr/stats/bin/ar border1.ottawa

This specification identifies when the job is to be executed and what the
command to be executed is. The cron daemon builds an internal list of the
jobs to be executed, and runs them at the requested time intervals.

syslog

The syslog daemon is a UDP/IP service that allows information and status
messages for different network services to be logged through a central
logging mechanism. The syslog daemon is controlled through the file
/etc/syslog.conf and can write messages of different types into different
log files. A sample syslog.conf file is shown here:

user.* /usr/log/user_logs
kern.* /usr/log/kernel_logs
daemon.* /usr/log/messages
mail.debug /usr/log/mail

etc. etc.

The syslog.conf file lists the facility priority level of the messages, and where
that message is to be stored when received. Any message that is received
with a priority level of critical, for example, is written to the file /usr/log/critical.

sendmail

The sendmail daemon is the common Mail Transport Agent included with current
versions of Unix. Because this program is a daemon, it listens for and accepts
incoming e-mail connections from external systems. This daemon receives and
subsequently delivers messages to local or remote users. Sendmail is not intended
to function as a user interface, but rather as the processing agent for user mail
programs such as elm, pine, mailx, and mush.

The sendmail program functions in two modes: incoming and outgoing. It accepts
mail from internal and external sources and processes it according to the rules
found in the /etc/sendmail.cf configuration file. The format of and options for
the /etc/sendmail.cf configuration file are far too complex to cover here.

The sendmail program is capable of accepting TCP/IP connections on port 25.
The following output illustrates a connection to sendmail on this port.

nms% telnet nms 25
Trying 198.53.64.4 ...
Connected to nms.
Escape character is '^]'.
220 nms.home.org Sendmail 4.1/ch-950121.1 ready at Thu, 18 May
95 11:28:36 CET
help
214-Commends:
214- HELO MAIL RCPT DATA RSET
214- NOOP QUIT HELP VRFY EXPN
214.For more info use "HELP ".
214-stmp
214-To report bugs in the implementation contact Sun Microsystems

214-Technical Support.
214-For local information contact postmaster at this site.
214-End of HELP info
quit
221 nms.home.org closing connection
nms%

The system administrator can test his or her configuration from the sendmail
command directly. Unfortunately, this capability can also be used by any wily hacker to create a false mail message that looks like it came from
a false address.

getty

The getty daemon is responsible for providing a login prompt on terminals
and on serial devices directly connected to the system; getty is also responsible
for providing a login prompt on the console. The getty command is started by
the init process, and is part of the login->shell->logout process. It is important
to note that when you log in through telnet, getty is not involved in the process.
The telnet server, telnetd, displays the login message and collects the user name
from the user.

rlogind

The rlogind daemon is the server side to the client rlogin program. It provides a
remote login facility with authentication based on privileged port numbers and
hostname-username pairs. rlogind is executed by the Internet daemon, inetd, when
it receives a service request at the port indicated in the services database for login
using the TCP/IP protocol.

deliver

The deliver daemon manages all mail delivery in the MMDF mail system. deliver does
not deliver mail directly, but instead calls on MMDF channel programs to handle
actual delivery. deliver's actions are guided by the MMDF configuration file, /usr/mmdf/
mmdftailor, and by command-line options. This daemon also maintains a cache of host
Information on a per-channel basis, so that mail for unavailable hosts can be skipped
until the host is available.

inetd

The inetd daemon listens on multiple ports for incoming connection requests. When
it receives a request, inetd spawns the appropriate server. The use of a "super-server"
allows other servers to be spawned only when needed and to terminate when they
have satisfied a particular request. The following servers are normally started by
inetd: fingerd, ftpd, rexecd, rlogind, rshd, talkd, telnetd, and tftpd. inetd can also
start several internal services: these are described in inetd.conf, which is typically
found in the /etc directory. Do not arrange for inetd to start named, routed, rwhod,
sendmail, pppd, or any NFS server.

routed

The routed daemon is invoked by root at boot time to manage the Internet Routing
Tables (usually during init 2). The routed daemon uses a variant of the Xerox NS
routing Information Protocol to maintain up-to-date kernel Routing Table entries.
If the host is an inter network router, routed periodically supplies copies of its Routing
Tables to hosts and networks that are directly connected.

nfsd

The nsfd daemon starts the NFS server daemons that handle client file system requests
the nsfd daemon is a user application entry point into the kernel-based NFS server.

mountd

The mountd daemon is an RPC server that responds to file system mount requests.
It reads the file /etc/exports to determine which file systems are available to which
machines and users. This daemon also provides information regarding clients with
mounted file systems. This information can be printed using the showmount command.

pcnfsd
The pcnfs daemon is an RPC server that supports ONC clients on PC (DOS, OS/2, and
MAC) systems. There are two implementations of the PC-NFS protocol: Version 1 and
Version 2. Version 2 supports extended printing features. It reads the configuration
file /etc/pcnfsd.conf if present, and then services RPC requests directed to program
number 150001. Many releases of the pcnfsd daemon support both version 1 and
version 2 of the pcnfsd protocol.

statd, rpc.statd

The statd and rpc.statd daemons are RPC servers that function as the RPC status
monitor. It interacts with the lockd server to provide crash and recovery functions for
the locking services on NFS. It is common to see either statd or rpc.statd but not both
on your system.

lockd, rpc.lockd

The lockd daemon processes lock requests that are either sent locally by the kernel
or remotely by another lock daemon. lockd forwards lock requests for remote data to
the server site's lock daemon. lockd then requests the status monitor daemon, statd
or rpc.statd, for monitor service. The reply to the lock request will not be sent to the
kernel until the status daemon and the server site's lock daemon have replied.

Feedback would be nice psyops@phault.org.

1.) Daemon
processes - psyops
2.)Analysis
: Implications of Internet Growth - CptZZap
3.)The Art of
IRC - JesterS
4.)Network
Stacks & TCP/IP - Liquid Sphear
5.)Basics of
Internet Investigations - madirish
6.)Proliferation of
the Internet
7.)Having fun
with system.ini - xearthed
8.)A look into
VPNs and setting one up - L33tdawg
9.)Review of
DIVA LAN ISDN Router - L33tdawg
10.)Strategies
for Tomorrows War - Cpt ZZap