-accounts vs access control:
. accounts are for individual users and define set of possible operations for that user. (eg what operations can user A do?)
. access control system is a set of potential user/operation pairs (eg can user A do operation x?)
-access control can be built into the kernel or into the file system. the former being the default.
-the defining characteristic of the root user is uid of 0.
-while it is possible to change the root user name or create additional users with uid 0 -- but that is a security risk.
-superuser is defined as the user with effective uid 0. the actual user name is root.
-superuser (ie proc with effective uid 0) allows itself to change its uid and gid.
-but once it assumes another uid,gid it cant go back.
-this happens for example in the login proc that starts as superuser but then becomes the uid,gid of the user that logs in.
-setuid, setgid based access control allow executable files to run with elevated permissions.
-Access control (kernel/fs) types:
. role based (rbac) - assign privs to roles and roles to users.
. mandatory (mac) - like selinux - prevents users from delegating access to their objects.
. pluggable (pam) - answers questions like 'is user x really x?'
. kerberos - pam defines the framework, kerberos defines the implementation, esp on remote hosts.
. filesystem (acl) - traditional acl based on user, group ownership.
-root login does not keep a log of actions. if multiple people have root access, one cant tell who logged as root and when.
-a slightly better way to log root is 'su'. It does not record the commands executed as root, but tells who became root and when.
-su is best reserved for emergencies.
-a still better way to log root is 'sudo'. sudo keeps detailed logs of actions, hosts, time stamps etc.
-using sudo means you can have only few or zero people with access to real root.
-sudo is faster than su and direct root login. also a single file can be used to control access for an entire network.
Saturday, January 8, 2011
Linux : Boot Process
-Bootstrapping
. is the process of starting up of the computer
. the computer starts itself, as the OS is not yet available at this stage.
. like a sleeping hiker who wakes up and pulls himself up with his own boot's straps, without external help.
. at a macro level, during bootstrap, the kernel is loaded into memory and begins to execute.
. at a micro level, during bootstrap, the boot code (BIOS) in ROM is executed foll by search, load & exec of kernel code.
. the search for the kernel requires knowing disk geometry. this is the info in the mbr that lives in 1st block of disk.
. usually the kernel resides in /boot/vmlinuz.
. once the kernel is running, it probes the hardware and starts the first process called init (pid = 1).
. after this, init starts subsequent processes, daemons and mounts filesystems.
=> Boot strap = BIOS > kernel > init > daemons
. If for some reason, the system can not complete the above steps (eg a damaged filesystem), then maintenance is reqd.
. To do this sort of maintenance, linux has the foll mode:
-maintenance mode a.k.a recovery mode a.k.a single user mode.
. in this mode, network access is not allowed and physical access to the system is needed.
-Two stage boot loading process:
. stage 1 - ROM BIOS code executes, locates mbr and loads bootloader into memory from disk.
. stage 2 - bootloader locates and loads kernel.
- kernel scans memory, creates memory area for system and user procs, prints memory details on console.
- then kernel then starts init. init lives in the user space.
- init then spawns other subsequent process and this completes the boot process.
-Once the BIOS has figured out which device it has to boot the system from, it searches the first block on that device.
-This first block is 512 bytes in size and is called MBR.
-The MBR tells the system where to look for the secondary boot program called the 'bootloader'; eg: grub.
-this bootloader then loads the kernel.
-GRUB was developed by GNU. Ships with most linux on Intel platforms.
-grubs job is to choose a kernel from a previously assembled list and load it.
-grub config file location is either /boot/grub/grub.conf or /boot/grub/menu.lst depending upon the system.
-In a multiboot system, each disk partition can have its own bootloader. but the system can have only one mbr.
-so when setting up a multiboot system, it is required to specify which of the partitions is the 'master'.
-the single user mode is not a real init state. It is an intermediate step to init 1. Its job is to prompt for root passwd.
-when the system is started from init 0, it reads inittab and runs the scripts for the default level.
-when the system is already started and init n comand is issued, the init state is changed to n.
-internally this is done using telinit cmd (ie to go from init n to init m: init n -> telinit m -> init m).
-telinit -q cmd forces init to re-read inittab file.
-system startup scripts live in /etc/rc.d dirs.
-service startup scripts live in /etc/init.d dir. These scripts allow user defined services to be started & stopped.
-shutdown halt does these:
. logs the shutdown
. kills non essential procs
. executes sync system call
. waits for fs writes to complete
. halts the kernel
-reboot is identical to shutdown except that it restarts the system.
. is the process of starting up of the computer
. the computer starts itself, as the OS is not yet available at this stage.
. like a sleeping hiker who wakes up and pulls himself up with his own boot's straps, without external help.
. at a macro level, during bootstrap, the kernel is loaded into memory and begins to execute.
. at a micro level, during bootstrap, the boot code (BIOS) in ROM is executed foll by search, load & exec of kernel code.
. the search for the kernel requires knowing disk geometry. this is the info in the mbr that lives in 1st block of disk.
. usually the kernel resides in /boot/vmlinuz.
. once the kernel is running, it probes the hardware and starts the first process called init (pid = 1).
. after this, init starts subsequent processes, daemons and mounts filesystems.
=> Boot strap = BIOS > kernel > init > daemons
. If for some reason, the system can not complete the above steps (eg a damaged filesystem), then maintenance is reqd.
. To do this sort of maintenance, linux has the foll mode:
-maintenance mode a.k.a recovery mode a.k.a single user mode.
. in this mode, network access is not allowed and physical access to the system is needed.
-Two stage boot loading process:
. stage 1 - ROM BIOS code executes, locates mbr and loads bootloader into memory from disk.
. stage 2 - bootloader locates and loads kernel.
- kernel scans memory, creates memory area for system and user procs, prints memory details on console.
- then kernel then starts init. init lives in the user space.
- init then spawns other subsequent process and this completes the boot process.
-Once the BIOS has figured out which device it has to boot the system from, it searches the first block on that device.
-This first block is 512 bytes in size and is called MBR.
-The MBR tells the system where to look for the secondary boot program called the 'bootloader'; eg: grub.
-this bootloader then loads the kernel.
-GRUB was developed by GNU. Ships with most linux on Intel platforms.
-grubs job is to choose a kernel from a previously assembled list and load it.
-grub config file location is either /boot/grub/grub.conf or /boot/grub/menu.lst depending upon the system.
-In a multiboot system, each disk partition can have its own bootloader. but the system can have only one mbr.
-so when setting up a multiboot system, it is required to specify which of the partitions is the 'master'.
-the single user mode is not a real init state. It is an intermediate step to init 1. Its job is to prompt for root passwd.
-when the system is started from init 0, it reads inittab and runs the scripts for the default level.
-when the system is already started and init n comand is issued, the init state is changed to n.
-internally this is done using telinit cmd (ie to go from init n to init m: init n -> telinit m -> init m).
-telinit -q cmd forces init to re-read inittab file.
-system startup scripts live in /etc/rc.d dirs.
-service startup scripts live in /etc/init.d dir. These scripts allow user defined services to be started & stopped.
-shutdown halt does these:
. logs the shutdown
. kills non essential procs
. executes sync system call
. waits for fs writes to complete
. halts the kernel
-reboot is identical to shutdown except that it restarts the system.
Subscribe to:
Posts (Atom)