History of MINIX 3

MINIX has a long history. It goes back to 1987 when the first edition of the book Operating Systems: Design and Implementation by Andrew S. Tanenbaum was published. The first version of MINIX was intended for teaching and it became very popular very quickly. One of the early users was a Finnish student, Linus Torvalds, who learned all about operating systems from reading the book and modifying the system. Eventually he went on to write his own operating system, Linux. In 2004, a man named Ken Brown accused Torvalds of copying MINIX verbatim, but that was quickly refuted in a statement published 20 May 2004 by Andrew Tanenbaum. A second edition of MINIX (and a second edition of the book, coauthored by Albert S. Woodhull) was released in 1997. This version was greatly improved from the first version but was still aimed at teaching operating systems to a large extent. It was only with the third version, MINIX 3, and the third version of the book, published in 2006, that the emphasis changed from teaching to a serious research and production system, especially for embedded systems. A few of the many differences between MINIX 2 and MINIX 3 are given here. Going forward, we are making a serious effort to turn MINIX 3 in an industrial-grade system with a focus on the embedded market, especially for those applications that need high reliability and availability.

[ Read More ]

Apache Configuration File Security Option

you’ll examine the security options available in the main Apache configuration file, httpd.conf. That file can be modified to secure the entire server or to configure security on a directory-by-directory basis. Directory controls secure access by the server, as well as users who connect to the web sites on the server. To explore the basics of Apache security, start with the first default active line in httpd.conf:

ServerTokens OS

This line looks deceptively simple; it limits the information displayed about a web server you navigate to a nonexistent page to the following message:

Apache/2.2.15 (Red Hat) Server at localhost Port 80

Contrast that output with what happens with a ServerTokens Full line:

Apache/2.2.15 (Red Hat) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.2

Python/2.6.5 mod_perl/2.0.4 Perl/v5.10.1 Server at localhost Port 80

In other words, with one option, outsiders can see whether modules such as Perl, Python, and PHP have been loaded, along with their version numbers. As not everyone updates their software in a perfectly timely manner, what happens when a cracker sees a version that has been compromised, your servers will face additional risks. Next, you can restrict access to the directory defined by the ServerRoot directive as shown here:

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

This configures a very restrictive set of permissions. The Options FollowSymLinks line supports the use of symbolic links for web pages. The AllowOverride None line disables any .htaccess files. The ServerRoot directive points to /etc/httpd, which contains Apache configuration files. Without the AllowOverride None line, a cracker who inserts a malicious .htaccess file can configure permissions that allows any user to change such configuration files. However, there’s an appropriate use for .htaccess files. For example, when placed in a subdirectory such as /www/html/project, then it can be used to permit access to a group, and such changes would apply only to that directory. You can improve this by limiting access to all but explicitly allowed users, by adding the following commands to the desired <Directory> container:

Order deny,allow

Deny from all

The next <Directory> container example limits access to /var/www/html, which corresponds to the default DocumentRoot directive (while these directives are divided by numerous comments, they are all in the same stanza):

<Directory /var/www/html>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

The Options directive is different; the Indexes setting allows readers to see a list of files on the web server if no index.html file is present in the specified directory. The Order and Allow lines allow all users to access the web pages on this server. Finally, the Listen directive defines the IP address and TCP/IP port for this server. For example, the default shown next means that this server will work with every computer that requests a web page from any of the IP addresses for your computer on the standard TCP/IP port, 80:

Listen 80

If more than one IP address is available on the local system, the Listen directive can be uses to limit access to one specific IP address. For example, if a system has two network cards with IP addresses 192.168.0.200 and 192.168.122.1, the following directive can help limit access to systems on the 192.168.122.0 network:

Listen 192.168.122.1:80

[ Read More ]

Apache and SELinux File Labels

Take a look at the SELinux settings associated with Apache. To review, SELinux settings, as they relate to a service, mostly fall into two categories: boolean settings and file labels. Start with the file labels.

Apache and SELinux File Labels

The default file labels for Apache configuration files are consistent, as shown in the output to the ls -Z /etc/httpd and ls -Z /var/www commands. Individual files use the same contexts as their directory. For web sites where scripts read and or append data to web forms, you’d consider the last two contexts, which support read/write (rw) and read/append (ra) access.

Create a Special Web Directory

In many cases, you’ll create dedicated directories for each virtual web site. It’s better to segregate the files for each web site in its own directory tree. But with SELinux, you can’t just create a special web directory. You’ll want to make sure that new directory at least matches the SELinux contexts of the default /var/www directory. Run the ls -Z /var/www command. Note the SELinux contexts. For most directories, the user context is system_u and the type is http_sys_content_t. For a newly created /www directory, you could just change the SELinux contexts with the following commands. The -R applies the changes recursively, so the new contexts are applied to files and subdirectories.

# chcon -R -u system_u /www/

# chcon -R -t httpd_sys_content_t /www/

Of course, if scripts are required for the associated web site, you’ll want to run the following command to make sure the SELinux changes survive a relabel:

# semanage fcontext -a -s system_u -t httpd_sys_content_t /www/

This command creates a file_contexts.local file in the /etc/selinux/targeted/ contexts/files directory. If there’s also a cgi-bin/ subdirectory, you’ll want to set up appropriate contexts for that subdirectory as well with the following command:

# semanage fcontext -a -s system_u -t httpd_sys_script_exec_t  /www/cgi-bin/

The differences in the file contexts are shown in Table

Directory	SELinux Context Type
/etc/httpd, /etc/httpd/conf, /etc/httpd/conf.d, /var/run/httpd	httpd_config_t
/usr/lib64/httpd/modules	httpd_modules_t
/var/log/httpd	httpd_log_t
/var/www, /var/www/error, /var/www/html, /var/www/icons, /var/www/manual, /var/www/usage	httpd_sys_content_t
/var/www/cgi-bin	httpd_sys_script_exec_t
n/a	httpd_sys_content_rw_t
n/a	httpd_sys_content_ra_t

[ Read More ]

Apache Port and Firewalls

With the Listen and NameVirtualHost directives, the Apache web server specifies the standard communication ports associated with both the HTTP and HTTPS protocols, 80 and 443. To allow external communication through the noted ports, you can set up both ports as trusted services in the Firewall Configuration tool. Of course, for systems where HTTP and HTTPS are configured on nonstandard ports, you’ll have to adjust the associated iptables rules accordingly. If you just open these ports indiscriminately, it allows traffic from all systems. It may be appropriate to set up a custom rule to limit access to one or more systems or networks. For example, the following custom rules allows access to every system on the 192.168.122.0 network except the one with IP address 192.168.122.150, over port 80. To review, these rules are applied to the iptables command, in order.

-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.122.150 --dport 80 -j REJECT

-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.122.0/24 --dport 80 -j ACCEPT

Similar rules may be required for port 443. Of course, that depends on the

requirements of the job.

[ Read More ]

Apache Log Files Details

Apache log files are configured in the /etc/httpd/logs directory, they’re actually stored in the /var/log/httpd directory. Standard logging information from Apache is stored in two baseline log files. Custom log files may also be configured. Such log files may have different names, depending on how virtual hosts are configured, how secure web sites are configured, and how logs are rotated.

Based on the standard Apache configuration files, access attempts are logged in the access_log file and errors are recorded in the error_log file. Standard secure log files include ssl_access_log, ssl_error_log, and ssl_request_log.

In general, it’s helpful to set up different sets of log files for different web sites. To that end, you should set up different log files for the secure versions of a web site. The traffic on a web site is important when choosing a log rotation frequency.

There are standard Apache log file formats. Four different formats: combined, common, the referrer (the web page with the link used to get to your site), and the agent (the user’s web browser). The first two LogFormat lines include a number of percent signs followed by lowercase letters. These directives determine what goes into the log.

# LogLevel: Control the number of messages logged to the error log.

# Possible values include: debug, info, notice, warn, error, crit,

# alert, emerg.

#

LogLevel warn

#

# The following directives define some format nicknames for use with

# a CustomLog directive (see below) .

#

LogFormat “%h %l $u %t \ “%r\” %>S %b \ “%{Referer}i\” \” ” combined

LogFormat “%h %l $u %t \ “%r\” %>S %b” common

LogFormat “ %{Referer}i” agent

LogFormat “ %{User-agent}i” agent

# “combinedio” includes actual counts of actual bytes received (%I) and send (%O) ; this

# requires the mod_logio module to be loaded.

# LogFormat “%h %l %u %u %t \  “%r” %?s %b \ “ %{Referer}i\” \ “%{User-Agent}i\” %I %O” combinedio

#

You can then use the CustomLog directive to select a location for the log file, such as logs/special_access_log, and the desired log file format, such as common. For more information on log files and formats, refer to http://localhost/manual/logs.html.

Some web log analyzers have specific requirements for log file formats. For example, the popular open-source tool awstats (advanced Web Stats) requires the combined log format. It will fail to run if you leave the default common format. Awstats is a great tool for graphically displaying site activity. You can download it from a site such as www.sourceforge.net.

[ Read More ]

Why sendmail Is So Complex?

In its simplest role, that of transporting mail from a user on one machine to another user on the same machine, sendmail is almost trivial. All vendors supply a sendmail (and a configuration file) that will accomplish this. But as your needs increase, the job of sendmail becomes more complicated, and its configuration file becomes more complex. On hosts that are connected to the Internet, for example, sendmail should use the Domain Name System (DNS) to translate hostnames into network addresses. Machines with UUCP connections, on the other hand, need to have sendmail run the uux program.

The sendmail program needs to transport mail between a wide variety of machines. Consequently, its configuration file is designed to be very flexible. This concept allows a single binary to be distributed to many machines, where the configuration file can be customized to suit particular needs. This configurability contributes to making sendmail complex.

When mail needs to be delivered to a particular user, for example, the sendmail program decides on the appropriate delivery method based on its configuration file. The decision process might include the following steps:

·         If the recipient receives mail on the same machine as the sender, sendmail delivers the mail using the /usr/sbin/mail.local program.

·         If the recipient’s machine is connected to the sending machine using UUCP, it uses uux to send the mail message.

·         If the recipient’s machine is on the Internet, the sending machine transports the mail using SMTP.

·         Otherwise, the mail message might need to be transported over another network (such as Bitnet) or possibly rejected.

[ Read More ]

Defination of MUA, MTA & MSA (sendmail)

MUA

A mail user agent (MUA) is any of the many programs that users run to read, reply to, compose, and dispose of email.

Examples of MUAs also exist for PCs. Eudora and Claris-Works are two standalone MUAs. Netscape and Explorer are web browsers that canalso act as MUAs. Thunderbird is an open source MUA from the folks at Mozilla. Many MUAs can exist on a single machine. MUAs sometimes perform limited mail transport, but this is usually a very complex task for which they are not suited.

MTA

A mail transfer agent (MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office does. Usually, there is only one MTA on a machine. The sendmail program is an MTA.

MSA

sendmail also recognizes the role of a mail submission agent (MSA), as defined in RFC2476. MTAs are not supposed to alter an email’s text, except to add Received:, Return-Path:, and other required headers. Email submitted by an MUA might require more modification than is legal for an MTA to perform, so the new role of an MSA was created. An MSA accepts messages from an MUA, and has the legal right to heavily add to, subtract from, and screen or alter all such email. An MSA, for example, can ensure that all hostnames are fully qualified, and that headers, such as Date:, are always included.

[ Read More ]

Mail Server Basic

Imagine yourself withpen and paper, writing a letter to a friend far away. You finish the letter and sign it, reflect on what you’ve written, then tuck the letter into an envelope. You put your friend’s address on the front, your return address in the lefthand corner, and a stamp in the righthand corner, and the letter is ready for mailing. Electronic mail (email for short) is prepared in much the same way, but a computer is used instead of pen and paper.

The post office transports real letters in real envelopes, whereas sendmail transports electronic letters in electronic envelopes. If your friend (the recipient) is in the same neighborhood (on the same machine), only a single post office (sendmail running locally) is involved. If your friend is in a distant location, the mail message will be forwarded from the local post office (sendmail running locally) to a distant one (sendmail running remotely) for delivery. Although sendmail is similar to a post office in many ways, it is superior in others:

·         Delivery typically takes seconds rather than days.

·         Address changes (forwarding) take effect immediately, and mail can be forwarded anywhere in the world.

·         Host addresses are looked up dynamically. Therefore, machines can be moved or renamed and email delivery will still succeed.

·         Mail can be delivered through programs that access other networks (such as Unix to Unix Communication Protocol [UUCP] and Bitnet). This would be like the post office using United Parcel Service to deliver an overnight letter.

[ Read More ]

Configuring a DHCP Client

To configure a DHCP client manually, modify the /etc/sysconfig/network file to enable networking and the configuration file for each network device in the  /etc/sysconfig/network-scripts directory. In this directory, each device should have a configuration file named ifcfg-eth0, where eth0 is the network device name.

The /etc/sysconfig/network-scripts/ifcfg-eth0 file should contain the following lines:

DEVICE=eth0

BOOTPROTO=dhcp

ONBOOT=yes

A configuration file is needed for each device to be configured to use DHCP.

Other options for the network script includes:

• DHCP_HOSTNAME — Only use this option if the DHCP server requires the client to specify a hostname before receiving an IP address. (The DHCP server daemon in Red Hat Enterprise Linux  does not support this feature.)
• PEERDNS=<answer> , where <answer> is one of the following:
• yes — Modify /etc/resolv.conf with information from the server. If using DHCP, then yes is the default.
• no — Do not modify /etc/resolv.conf.

[ Read More ]

Starting and Stopping the DHCP Server

When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. Use the command touch /var/lib/dhcpd/dhcpd.leases to create the file if it does not exist.

If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file.

To start the DHCP service, use the command /sbin/service dhcpd start. To stop the DHCP server, use the command /sbin/service dhcpd stop.

By default, the DHCP service does not start at boot time.  To configure the daemon to start automatically at boot time.

If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:

# Command line options here

DHCPDARGS=eth0

This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.

Other command line options that can be specified in /etc/sysconfig/dhcpd include:

• -p <portnum> — Specifies the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responses to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified.
• -f — Runs the daemon as a foreground process. This is mostly used for debugging.
• -d — Logs the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages.
• -cf <filename> — Specifies the location of the configuration file. The default location is /etc/dhcp/dhcpd.conf.
• -lf <filename> — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcpd/dhcpd.leases.
• -q — Do not print the entire copyright message when starting the daemon.

[ Read More ]

DHCP Lease Database

On the DHCP server, the file /var/lib/dhcpd/dhcpd.leases stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.

All times in the lease database are in Coordinated Universal Time (UTC), not local time.

The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~ and the temporary lease database is written to dhcpd.leases.

The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

[ Read More ]

Dhcp configuration file Example

Example Subnet Declaration

subnet 192.168.1.0 netmask 255.255.255.0 {

        option routers                  192.168.1.254;

        option subnet-mask              255.255.255.0;

        option domain-search              "example.com";

        option domain-name-servers       192.168.1.1;

        option time-offset              -18000;     # Eastern Standard Time

        range 192.168.1.10 192.168.1.100;

}

To configure a DHCP server that leases a dynamic IP address to a system within a subnet, modify “Range Parameter” with your values. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns IP addresses in the range192.168.1.10 and 192.168.1.100 to client systems.

Range Parameter

default-lease-time 600;

max-lease-time 7200;

option subnet-mask 255.255.255.0;

option broadcast-address 192.168.1.255;

option routers 192.168.1.254;

option domain-name-servers 192.168.1.1, 192.168.1.2;

option domain-search "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {

   range 192.168.1.10 192.168.1.100;

}

 To assign an IP address to a client based on the MAC address of the Network interface card, use the hardware ethernet parameter within a hostdeclaration. As demonstrated in "Static IP Address using DHCP", the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4.

Note that the optional parameter host-name can also be used to assign a host name to the client.

Static IP Address using DHCP

host apex {

   option host-name "apex.example.com";

   hardware ethernet 00:A0:78:8E:9E:AA;

   fixed-address 192.168.1.4;

}

All subnets that share the same physical network should be declared within a shared-network declaration as shown in "Shared-network Declaration". Parameters within the shared-network, but outside the enclosed subnet declarations, are considered to be global parameters. The name of the shared-network must be a descriptive title for the network, such as using the title 'test-lab' to describe all the subnets in a test lab environment.

Shared-network Declaration

shared-network name {

    option domain-search              "test.redhat.com";

    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;

    option routers                  192.168.0.254;

    more parameters for EXAMPLE shared-network

    subnet 192.168.1.0 netmask 255.255.252.0 {

        parameters for subnet

        range 192.168.1.1 192.168.1.254;

    }

    subnet 192.168.2.0 netmask 255.255.252.0 {

        parameters for subnet

        range 192.168.2.1 192.168.2.254;

    }

}

As demonstrated in "Group Declaration", the group declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.

Group Declaration

group {

   option routers                  192.168.1.254;

   option subnet-mask              255.255.255.0;

   option domain-search              "example.com";

   option domain-name-servers       192.168.1.1;

   option time-offset              -18000;     # Eastern Standard Time

   host apex {

      option host-name "apex.example.com";

      hardware ethernet 00:A0:78:8E:9E:AA;

      fixed-address 192.168.1.4;

   }

   host raleigh {

      option host-name "raleigh.example.com";

      hardware ethernet 00:A1:DD:74:C3:F2;

      fixed-address 192.168.1.6;

   }

}

[ Read More ]