ATAD #21 – Linux process priority range

The Linux kernel implements two separate priority ranges.

The first is the nice value, a number from –20 to 19 with a default of zero. Larger nice values correspond to a lower priority (you are being nice to the other processes on the system). Processes with a lower nice value (higher priority) run before processes with a higher nice value (lower priority). The nice value also helps determine how long a processor timeslice the process receives. A process with a nice value of –20 receives the maximum timeslice, whereas a process with a nice value of 19 receives the minimum timeslice. Nice values are the standard priority range used in all Unix systems.

The second range is the real-time priority (rtprio). By default, it ranges from zero to 99. All real-time processes are at a higher priority than normal processes. Linux implements real-time priorities in accordance with POSIX.

In order to select a process to run, the Linux scheduler must consider the priority of each process. Actually, there are two kinds of priority:

Static priority
This kind is assigned by the users to real-time processes and ranges from 1 to 99 (highest). It is never changed by the scheduler. The sys_sched_get_priority_max( ) routine returns the static priority of the process, it returns 0 for non-realtime processes.

Dynamic priority
This kind applies only to conventional processes (non realtime processes)

Processes have an initial priority specified as the nice value. This value is stored in the static_prio member of the process’s task_struct. The value is called the static priority because it does not change from what the user specifies. The scheduler, in turn, bases its decisions on the dynamic priority that is stored in prio. The dynamic priority is calculated as a function of the static priority and the task’s interactivity

The static priority of a real-time process is always higher than the dynamic priority of a conventional one: the scheduler will start running conventional processes only when there is no real-time process in a TASK_RUNNING state.

.

Do experiment with the ps command

~$ ps -eo pid,rtprio,ni,pri,comm
PID RTPRIO  NI PRI COMMAND
1      -   0  19 init
2      -  -5  24 kthreadd
3     99   - 139 migration/0
4      -  -5  24 ksoftirqd/0

.

This scale could probably illustrate priorities better

HIGH PRIORITY – – – – – > – – – – – > – – – – – > – – – – – > – – – – LEAST PRIORITY
……..real time priority (static priority)…….| …. nice value (dynamic priority) …..
99 ……………………….. 50 ……………………… 1 | -20 …….. -10 …….. 0 …….. 10 ……. 19

.

Further Reading: Linux Process Scheduler, Linux Process Scheduling

__tipped__
–vinaydeep

ATAD #19 – Linux login program

The login program is used when signing onto a system. It can also be used to switch from one user to another at any time (most modern shells have support for this feature built into them, however).

If an argument is not given, login prompts for the username.

If the user is not root, and if /etc/nologin exists, the contents of this file are printed to the screen, and the login is terminated. This is typically used to prevent logins when the system is being taken down.

If special access restrictions are specified for the user in /etc/usertty, these must be met, or the log in attempt will be denied and a syslog message will be generated.

If the user is root, then the login must be occurring on a tty listed in /etc/securetty. Failures will be logged with the syslog facility. If the file does not exist, root is allowed to log in on any tty.

After these conditions have been checked, the password will be requested and checked (if a password is required for this username). Ten attempts are allowed before login dies, but after the first three, the response starts to get very slow. Login failures are reported via the syslog facility. This facility is also used to report any successful root logins.

If the file .hushlogin exists, then a “quiet” login is performed (this disables the checking of mail and the printing of the last login time and message of the day). Otherwise, if /var/log/lastlog exists, the last login time is printed (and the current login is recorded).

Random administrative things, such as setting the UID and GID of the tty are performed. The TERM environment variable is preserved, if it exists (other environment variables are preserved if the -p option is used). Then the HOME, PATH, SHELL, TERM, MAIL, and LOGNAME environment variables are set. PATH defaults to /usr/local/bin:/bin:/usr/bin for normal users, and to /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin for root. Last, if this is not a “quiet” login, the message of the day is printed and the file with the user’s name in /var/spool/mail will be checked, and a message printed if it has non-zero length.

The user’s shell is then started. If no shell is specified for the user in /etc/passwd, then /bin/sh is used. If there is no directory specified in /etc/passwd, then / is used (the home directory is checked for the .hushlogin file described above).

Further Reading: nologin, /etc/passwd, /etc/shadow, PAM Pluggable Authentication Modules

__tipped__

ATAD #12 – Securing your DNS

DNS exploits broadly fall in the category of cache poisoning (DNS spoofing where incorrect information is introduced in the DNS cache), client flooding (attacker floods false responses pretending to be a nameserver), dynamic update vulnerability (exploits weak authentication during zone updates between distributed nameservers), information leakage (attacker can extract internal information during zone transfers), and compromise of the DNS server’s authoritative database (attacker obtains administrative previlidges).

The most recent of the DNS expliots whose code can be found here, implements an intelligent cache poisoning algorithm.

The following topics could be of interest while considering DNS security

1. Carefully written named.conf
   – have DNS keys in a separate file and use the include statement to reference it.
   – backup your named.conf
   – use view and the match-clients statements to restrict information to limited clients.
2. Better designed zone updates
   – Use of TSIG (Transaction SIGnatures) or TKEY which allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.
   – Use of Access Control Lists (ACLs) provided by BIND which allow simple IP address protection.
3. Cryptographically Signed Zones
   – Use of DNSSEC which allows for zones to be cryptographically signed with a zone key.This way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver’s public key. This indeed would add considerable overhead but would prevent cache poisoning exploits.

If there is way to secure a system, some smart guy will invariably come up with a way to exploit an undiscovered vulnerability. These exploits, if not prevented, can atleast be curtailed by good system administration practices, regular system monitoring and updates.

Furthur Reading: DNS Security Extensions, DNS and BIND

__tipped__

ATAD #9 – Linux init and runlevels

A runlevel is a state or mode of operation of the operating system. Runlevels define what services or processes should be running on the system which are listed in the /etc/rc.d/rc(x).d (where x is the number of the runlevel) directory in linux. After init is invoked as the last step of the kernel boot sequence, it looks for the file /etc/inittab file for the default runlevel.

# Default runlevel. The runlevels used by RHS are:

#   0 – halt (Do NOT set initdefault to this).
#   1 – Single user mode. Only the root user can log in.
#   2 – Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 – Full multiuser mode with networking
#       This is the most common runlevel for server based systems that do not require GUI.
#   4 – unused or user defined.
#   5 – X11
#       Networked, multi-user state with X Window System capability
#   6 – reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

The runlevel program can be used to determing to the current runlevel of the system and the telinit program can be used to change the runlevel of the system on the fly. Note that its also possiblesupply init with the desired runlevel by specifying it as a kernel command line parameter from the grub bootloader (kernel /vmlinuz ro root=/dev/hda1 5)

__tipped__

ATAD #5 – What’s that SysRq key on your keyboard?

The SysRq key is used to give input to the operating system without interfering with the software running (or rather hanged, which you can figure out later in the post) on your system. In essence it’s a BIOS routine that triggers INIT 15, bypassing INIT 9 from reading the scan code, and thus the key pressed thereafter is not stored in the keyboard buffer, and to which the kernel will respond to. This will work unless the kernel is completely locked up, in which case you can give another try after tapping the Alt keys a couple of times or will have to head to the nearest “power” button.

In the Linux world the Alt + SysRq key is termed the Magic SysRq key that can be used to fix or debug a frozen system.

It’s required to turn on SysRq in order to use it. So make sure this is done after your system installation in case you forecast (pun intended) a system hang. You can do this by setting the kernel parameter, which is in extension of my previous post on linux proc fs

# echo 1 > /proc/sys/kernel/sysrq

On X86 machines you can press ALT-SysRq-(command) to send useful commands (also listed in the wiki article) to the kernel.

ALT-SysRq-C can be used to manually trigger a ‘C’rashdump when the system has hanged.

ALT-SysRq-REISUB can be used to manually trigger a neat and safe reboot when your machine has hanged, instead of pounding on the power button and risking HDD problems in the event where data is being written when the system hanged. Its easier remembered as BUSIER spelled in reverse.

And here is what’s happening under the hood
R turns off keyboard raw mode and sets it to XLATE / gives back control of the keyboard
E send a SIGTERM to all processes, except for init.
I send a SIGKILL to all processes, except for init
S attempt to sync all mounted filesystems
U mounts all filesystem as read-only to prevent a fsck at reboot
B reboots the system no matter what

__tipped__

ATAD #4 – Where is your OS bootable partition?

>The /boot/ partition (or) directory contains static files, like the kernel, that are required to boot the system properly.

The /boot/ partition _can_not_ be on a logical volume group because the boot loader can not read it. If the root / partition is on a logical volume, then its required to create a separate /boot/ partition which is not a part of a volume group. If you are making a RAID partition of /boot/, you must choose RAID level 1, and it must use one of the first two drives (IDE first, SCSI second). Source [RHEL deployment guide]

A neat description of the boot process can be found here

Btw just noticed that MS Windows does support the use of “/” and “\” to traverse across directories. neato. 🙂

__tipped__

ATAD #1 – linux /proc filesystem

It’s been a long time since i really sat down to read something, apart from what work demanded, technology round ups and reviews. Its this strange time in my life when academic acumen kicks in, and I wonder; “why not spend a few minutes each day to learn something new”.
I will log my learning’s with A Tip A Day.

Over the years I have understood that the /proc directory (also called the proc file system) contains files that store information about the state of the linux kernel and the running applications. The files can be interpreted by applications and the users (though a few are restricted only to the ‘root’ user) to gain a whole wealth of information about the running system. The contents of the files under the proc directory can be easily read using the cat program

OK, this is probably stale news for a few. But an interesting find was that a few files under /proc/sys can actually also be used to adjust settings to the kernel.

Eg, here im changing the hostname of the linux system to hoohaha

# echo hoohaha > /proc/sys/kernel/hostname

A few others store boolean information, for example the /proc/sys/net/ipv4/ip_forward when set to 1 will immediately start forwarding network packets.

# echo 1 > /proc/sys/net/ipv4/ip_forward

__tipped__