CEG 499/699:
Internet Security


College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001

From Powering up to Login Prompt

 

Prabhaker Mateti

 
Abstract:  We describe how a typical OS boots from powering up to login prompt.
 
This work is supported in part by NSF DUE-9951380.
  07/10/00

Table of Contents

  1. Educational Objectives
  2. Lab Experiment
  3. Acknowledgements
  4. References

Educational Objectives

  1. Understand how a computer system boots from power-on.
  2. Recognize the possibilities for Trojans.
  3. Recognize unneeded daemons.
  4. Develop a sense of proper configuration

The Process of Booting

[These were notes taken by former students of CEG 499 as I lectured.]

This discussion is specific to an OS (such as Unix) and an architecture (such as ix86 PC).   But similar steps are valid for other computer systems. So that a technique is understood, we often gloss over the details, even if it is at the risk of precision, but not at the level of "whole truth."

System Startup: Two states a) Power Off b) Power On

State: Power off.  Q: Is CPU Working? A: No.

State: Power On; Hard Disk motor speeds up. Q: What should CPU do when power is first applied?

A: The moment it is on, CPU Fetches, Decodes and Executes instructions. Q: So who points to this instruction? Program counter is an internal register of CPU.  Program counter gives this instruction address and its value increases. And this increment of pc value is done in decoding phase so that next instruction can be properly located.

Q: What is the first value that the pc has? A: Value is typically zero but need not be; can also be some other number.

Q: Now how do we make sure that the PC value is zero initially?
A: When powered on the RESET SIGNAL will cause the CPU to make the pc Value to Zero. So CPU should do the Zero instruction first and now the fetch decode, execute is started.  Reset Signal is not only wired to CPU but also to Sub Systems  E.g., Monitor. All Sub Systems have to be powered on.

Q: What should be there in Memory location Zero? A: A valid instruction.

Q: What type o f memory is it? A: Not a RAM.

Q: From the moment the machine is powered on to the moment when you can see the first Character on the screen what happened?

Q: BIOS, what does it do? BIOS contains many routines. When instructions are executed from address zero on wards, BIOS routines are called. E.g., Display a character onto the screen. All the routines that accomplish this task of printing a character on to the screen can be considered together as a device driver.  An the BIOS contains such drivers for many devices: kbd, hdd, floppy, video, etc. BIOS device drivers are limited. BIOS has minimally functional drivers.  Some OS (e.g., Linux) avoid non re-entrant code and avoid BIOS routines. 

The Power On self Test (POST) is a test that BIOS performs from the power-on moment till we begin to see the characters on the screen. Even if a video monitor is not there to show these messages, it communicate via other means such as it beeps. 

Q: OS is not in ROM.  It is on the hard disk.  How do we choose the starting point to load the OS code? A: pc should be set to that. After the instruction at zero has loaded the OS code on the starting position then you can jump to the OS code. So somewhere the BIOS routines will read from the Hard disk and put the OS code below the BIOS space. And then the routine jumps to this code.

Note: New OS do not use BIOS routines. Its not necessary that all BIOS routines be executed.

Q: What is the size of OS code that is loaded by the BIOS routine discussed above? A: 512 Bytes.  This code is part of MBR (master boot record) as it is known in the PC world.  Its main job is to bring more data from the hard disk.  Now in this 512 Bytes, there should be another program. And this program can bring more data from the hard disk and will be loaded further below in the mem.  The program that is brought in is usually the OS Loader.

Q: What is the size of Kernel? A: widely ranges. Let us say ½ to 2 meg and this has to be brought in and placed below the above mentioned 512 bytes.

Q: How do you identify starting position of MBR?  "First" track, first sector.  First track is usually numbered zero. 

Q: It’s the job of OS loader to bring Kernel.  Why cant MBR itself bring the Kernel. A: its not capable of bringing the Kernel because of MBR's small size. So MBR gets the OS loader  and that in turn loads the Kernel.  In our OSIS (Operating Systems and Internet Security) Lab machines, the OS Loader is NT Loader.  OS Loader can bring-in and pass control over to yet another porgram.  Lets say OS loader gets the OS. So now OS is loaded. Now CPU invokes instructions from the OS. 

Os will bring its own device drivers and may or may not use BIOS routines.  All devices are initilized.

Privileged instruction only when CPU is in the supervised mode. During the process of getting data from initial to OS loader the CPU is in privileged mode. This is a good place to do bad things. OS now loaded can change MBR so that next time when system boots up another program runs. And this is called boot sector infection.

A good OS will switch to the user mode as soon as possible. OS Designers try to get privileged mode off , Memory management on as soon as possible.

Contents of OS (not OS Loader): 1) Device Drivers 2) File system. ( it includes algorithms, while file volume is passive stuff on the hdd without algorithms) 3) Memory management. 4) Process management (creation, destruction and control of processes)

The above four together can be called a Kernel.

OS is now able to create the very first process. In Unix, it is called Init. As yet we have not seen the login prompt. Only choice user had so far was OS loader asked the user which OS the user wished to boot into, and we choose Linux.

Init Process

The init process is essentially table driven. It looks into a file re what it has to do.  It is usually located at /etc/inittab.  It's like a bunch of rules. Init process reads this file and acts accordingly.

Rc.boot is a shell script.  Init  invokes rc.boot via the shell. A shell is invoked as an interpreter for statements in rc.boot.  Bash is an example shell.  It is a compiled program and init invokes bash shell and executes line by line statements of rc.boot.

Rc.multiuser:  There is yet another condition in the /etc/inittab which invokes rc.multiuser. OS says: Now that I am in full control,  I allow multiple users. Before this the OS was in single user mode, i.e., the root . 

Getty

This is another program.  Other programs discussed above do their jobs and die but getty should not die. For every PORT we run one getty program.  What does getty do? Getty prompts with "login:".  When it receives input, it runs the program called /bin/login. This is a compiled binary program.  When you have typed your user-id,  /bin/login starts running. It takes the login and password. Passwords are stored in an encrypted from in a file /etc/Password.

Init lives . Its  watches getty  processes. Just in case a getty dies, it will start another Getty.

On To the Login Prompt

The following are some of the important processes that are created during the startup of a typical Unix (including Linux) system.

The first letter of some processes is k.  The letter k indicates processes that are kernel processes.  Similarly the tail letter 'd' indicates  processes that are commonly called Daemons. The daemons are alive while the OS is alive and fully functional.  A death of a daemon is a sign of something gone wrong with the system.

INIT: Init is the first process created by the kernel. Its process (PID) is a 1.  It is by far the most important process.  Init process is running while the operating system is alive. This process has to continuously run in order to keep the OS completely functional and if we happen to kill this process due to some reason the system is surely going to crash.

'SYSLOGD': The syslogd process is a daemon that logs all system events into a text file, typically /var/log/messages. The system administrator determines which events are worth keeping track of.  This is a very important process in terms of security since the attacker takes care to see that he eludes this process from monitoring his events. Only an incompetent attacker tries to kill this process, which makes it too obvious to the system administrator that something is wrong with the system. Killing of this process does not damage the system's functionality, but a further log of events stops.

'KLOGD': The 'klogd' process is very similar to the syslogd process but it monitors the events of the kernel. This process records the return values of the functions that are run, and creates a log file so that it is available for fault detection at a later time.

INETD: This is the "server of servers" through which all network serving connections are established. For example, if some other machine requests a telnet connection the, inetd process grants the connection.  In this action, two configuration files /etc/inetd.conf and /etc/services are consulted.

RPC.PORTMAP: As the name suggests, this process contains the map of all the active ports of the system. The abbreviation rpc stands for Remote Procedure Calls. This process allocates the port for a request by a local server, and can answer a remote clients regarding where a certain service is listening..

LPD: This is the printing services daemon. This process controls all the printing activities on the system.

HTTPD: The collection of the httpd processes is is the web server running on the system. This web server takes the request from the  user's browser and gives back the required HTML file. The program called Apache, is our httpd  on Linux.  

GETTY: The getty processes run on  different virtual terminals on the Linux system. The getty process is in charge of a user's attempt to login.  The following events occur.

1. The login name entry  causes the getty + login program to get the actual password from the database of the system.  The password so obtained is in an encrypted form. 

2. User enters the password.  This  password  is then encrypted using the same encryption algorithm.  The result is compared with the password obtained from the data base. 

3. If the two match, the user is allowed to log into the system and a shell is started at this point.

The 'getty' process runs till the user is logged in. That is at the 'login' prompt the process that is in control is 'getty'.  Once the user is logged in, the shell is started.  The shell takes over the console from 'getty'.  Eventually the user logs out.  After the user logs out,  the login prompt reappears and the console is back in the control of  'getty'.

The moment of looking up the password (in an encrypted form) and matching it with the password entered is a  vulnerable point.  There are programs which can 'sniff' the password entered.  There are programs that can systematically 'guess' a password.  They may succeed after a zillion attempts, but at the rate of, say, 1000 password-guesses/second, it will not take very long.


Lab Experiment

All work should be carried out in Operating Systems and Internet Security (OSIS) Lab, 429 Russ.   No other WSU facilities are allowed.

Describe the Missing Processes

Objective:  Make you study the booting sequence ending at login prompt.

  1. If the PC is running, shut it down properly.
  2. Freshly reboot into Linux. 
  3. Login.  No need to login as root.
  4. Save the output of ps -aux. 
  5. You will notice several gaps in the process id numbers.  Consider process ids in the range of 1 to 100.  Note the missing ids. Among the missing ids, explain the details of at least five processes that must have come to life, performed their duties, and terminated.  Be aware that the bash shell has many built in commands such as echo.
  6. Among the currently running processes, identify all the daemon processes, and how and where from they were invoked.

Turn in a Lab Report explaining the above details.


Acknowledgements

These were notes taken by former students of CEG 499 as I lectured.


References

  1. Lars Wirzenius, "Linux Administrators' Guide," file:/usr/doc/html/sag/index.html  Recommended Reading.  Required "skimming."
  2. Linux HOWTOs are installed on each PC in the OSIS lab.  Look under /usr/doc/HOWTO/.  Recommended Reading.  Required "skimming."
  3. SAGE, the System Administrators Guild, http://www.usenix.org/sage/   Required "visit."
07/10/00 09:55:10 AM
pmateti@cs.wright.edu