Root Password Security

• Introduction
• Limiting protocols that can initiate root login to SSH and restricting IP space within this daemon
• Controlling root logins
• Secure  vs unsecure terminals
• Spoofed Logins
• Red Hat Administrative Controls

Introduction

There are half-dozen classic ways to improve security of root account

1. Limiting connections to ssh and within ssh limit IP address space which can connect to the server
   • In more extreme form this idea leads to disabling root logins  In such cases you need to rely on sudo  and su for users to perform all operations requiring root access.
2. Implementing  the wheel group  which defines subset of users who can become root.  Wheel group was invented by BSD team and is a standard feature of BSD Unix. Another mechanism to implement wheel group, typically used in Linux is using a  special PAM module pam_wheel.so or similar modules
3. Limiting terminals on which root can login via /etc/security/access.conf
4. Using Solaris RBAC. Solaris and AIX 6 provide an additional set of features, known as RBAC that can make root account more secure by making it possible to delegate parts of root capabilities to other accounts.
5. Restrict Root's Search Path A common method used by crackers is to copy modified versions of system commands, called Trojan Horses  into a hacked system's directory structure. In a properly configured file system, they should only be able to put these programs in non-standard locations. To defend against the accidental execution of a Trojan horse program by root, make sure the current directory (.) is the last not the first member of the PATH environment variable. Root's search path should be restricted to directories owned by root, such as /usr/bin:/sbin:/usr/sbin, and you should generally use a fully justified filename when executing applications.
6. Check Files Sourced When Root Logs In. This is part of a defense-in-depth strategy to protect the root account. Making sure that root does not source files that are not owned by root, or files that are group and/or world writable makes it harder for a non-privileged user to subvert the root account.  Root profile and related dot files generally should have permissions 600.
7. Use separate directory /root as root home and set permissions on it to 700.
8. Set Root's File Mask. In case a higher level of security is desirable, you can set root's umask to  027 or even to 022. Add the following entry in root's .profile:

   umask 077

   When this is done, all files or directories created by root will have permissions:

   1. rwx------ (if umask=077 is used)
   2. rwxr-x--- (umask=027) 

In large corporate environment that main danger is the problem of shared root access: the situation when there are multiple administrators and application owners (the letter temporarily) can became root. Often members of such groups as database group and other application groups insist on being able to switch to root to perform specific tasks. This is a serious probloem does not have a clean solutions.

Sometimes you can use sudo to provide the ability to execute a selected program as root (for example Oracle installer), but generally this is difficult and almost unsolvable problem that creates many real SNAFUs with downtime and sometimes damage to data. 

To grants temporary access to root a good method is to enroll particular person temporary into wheel group and provide in sudo passwordless switch to root for members of this group. First of all in this case you do not need to communicate the password. Secondly this is very useful feature foe sysadmin themselves, as one typical problem which sysadmin face with amazing regularity is when they need to access the server but nobody knows the root password for it. If wheel group is implemented in sudo as gateway to root you need to know only you account password, which is much easier task.  This can be achieved by using the following directive in /etc/sudoers file:

%wheel ALL = (ALL) ALL 

Some people are addicted to power and in IT environment this addiction demonstrates itself as a quest to obtain root access to as many systems as one can.  It is very difficult to stop those people until a major incident occurs.

Limiting protocols that can initiate root login to SSH and restricting IP space within this daemon

One important difference between external hackers and regular users is the set of IP addresses used. While this is not always true (zombie PC are pretty common those days) this is true enough to warrant some actions complicating break-ins from IP-space distinct from IP-space in which regular users of this system operate.

One solution is to disable direct access to your root ID for telnet, rsh and other client with non-encrypted clients and to limit ability to log-in to root using SSH to "trusted IPs" (static IPs on internal network which have records in DNS). 

Please note that there is nothing wrong with using telnet by regular corporate users despite it being a less secure protocol then SSH (actually the number of successful break-ins via Open SSH exploits probably exceeds number of exploits using telnet; at one point OpenSSH exploits were the most popular way to break-in into ISPs  ;-). This is connected with the fact that in a typical large corporate usage telnet is used either on the local network with dedicated IP space (usually 10.x.x.x network) or via VPN connection.  In both situation attacks are possible but pretty difficult to execute:

• To sniff telnet session on local network you need either to break into the client, which is typically a Windows PC  (and in this case all bets are off, no matter which protocol is used) or  the attacker needs to flood the switch so that start functioning as hub. Mac table poisoning usually does not work with  enterprise class of switches used in corporate environment and flooding the switch usually has other detectable side effects that instantly brings attention to the fact.  
• On VPN connection the only way to sniff telnet session is to break into the client. Otherwise it is as secure as SSH without certificates. 

That's why I suspect that all this cheap talk about telnet insecurity that is so popular in shallow security books and articles has somewhat weak connection to reality. 

As ssh most often is compiled with TCP wrappers they can be used to limit IP space for the daemon.

Controlling root logins

The other method is that you can periodically reset root password using random password generator and to communicate it only when there is explicit need to use it (for example Tivoli client installations). In this case system administrators need to use sudo to obtain root privileges which limits the set of person eligible to the wheel group. Using sudo also allows you to monitor which users gained root access, as well as the time of their action. Su also has some logging capabilities and you can view su log ( /var/logs/sulog on Linux) and /var/adm/sulog on Solaris. Another alternative is to enable system auditing, which will report detailed activity for each account.

To disable remote login access for your root user, edit the /etc/security/access.conf file. It has quote a bit of interesting capabilities:

# Login access control table.
#
# Comment line must start with "#", no space at front.
# Order of lines is important.
#
# When someone logs in, the table is scanned for the first entry that
# matches the (user, host) combination, or, in case of non-networked
# logins, the first entry that matches the (user, tty) combination.  The
# permissions field of that table entry determines whether the login will
# be accepted or refused.
#
# Format of the login access control table is three fields separated by a
# ":" character:
#
# [Note, if you supply a 'fieldsep=|' argument to the pam_access.so
# module, you can change the field separation character to be
# '|'. This is useful for configurations where you are trying to use
# pam_access with X applications that provide PAM_TTY values that are
# the display variable like "host:0".]
#
#       permission : users : origins
#
# The first field should be a "+" (access granted) or "-" (access denied)
# character.
#
# The second field should be a list of one or more login names, group
# names, or ALL (always matches). A pattern of the form user@host is
# matched when the login name matches the "user" part, and when the
# "host" part matches the local machine name.
#
# The third field should be a list of one or more tty names (for
# non-networked logins), host names, domain names (begin with "."), host
# addresses, internet network numbers (end with "."), ALL (always
# matches), NONE (matches no tty on non-networked logins) or
# LOCAL (matches any string that does not contain a "." character).
#
# You can use @netgroupname in host or user patterns; this even works
# for @usergroup@@hostgroup patterns.
#
# The EXCEPT operator makes it possible to write very compact rules.
#
# The group file is searched only when a name does not match that of the
# logged-in user. Both the user's primary group is matched, as well as
# groups in which users are explicitly listed.
#
# TTY NAMES: Must be in the form returned by ttyname(3) less the initial
# "/dev" (e.g. tty1 or vc/1)
#
##############################################################################
#
# Disallow non-root logins on tty1
#
#-:ALL EXCEPT root:tty1
#
# Disallow console logins to all but a few accounts.
#
#-:ALL EXCEPT wheel shutdown sync:LOCAL
#
# Disallow non-local logins to privileged accounts (group wheel).
#
#-:wheel:ALL EXCEPT LOCAL .win.tue.nl
#
# Some accounts are not allowed to login from anywhere:
#
#-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL
#
# All other accounts are allowed to login from anywhere.
#
##############################################################################
# All lines from here up to the end are building a more complex example.
##############################################################################
#
# User "root" should be allowed to get access via cron .. tty5 tty6.
#+ : root : cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6
#
# User "root" should be allowed to get access from hosts with ip addresses.
#+ : root : 192.168.200.1 192.168.200.4 192.168.200.9
#+ : root : 127.0.0.1
#
# User "root" should get access from network 192.168.201.
# This term will be evaluated by string matching.
# comment: It might be better to use network/netmask instead.
#          The same is 192.168.201.0/24 or 192.168.201.0/255.255.255.0
#+ : root : 192.168.201.
#
# User "root" should be able to have access from domain.
# Uses string matching also.
#+ : root : .foo.bar.org
#
# User "root" should be denied to get access from all other sources.
#- : root : ALL
#
# User "foo" and members of netgroup "nis_group" should be
# allowed to get access from all sources.
# This will only work if netgroup service is available.
#+ : @nis_group foo : ALL
#
# User "john" should get access from ipv4 net/mask
#+ : john : 127.0.0.0/24
#
# User "john" should get access from ipv4 as ipv6 net/mask
#+ : john : ::ffff:127.0.0.0/127
#
# User "john" should get access from ipv6 host address
#+ : john : 2001:4ca0:0:101::1
#
# User "john" should get access from ipv6 host address (same as above)
#+ : john : 2001:4ca0:0:101:0:0:0:1
#
# User "john" should get access from ipv6 net/mask
#+ : john : 2001:4ca0:0:101::/64
#
# All other users should be denied to get access from all sources.
#- : ALL : ALL

Before you disable the remote root login, examine and plan for situations that would prevent a system administrator from logging in under a non-root user ID. For example, if a user's home file system is full, the user would not be able to log in. If the remote root login were disabled and the user who could use the su - command to change to root had a full home file system, root could never take control of the system. This issue can be bypassed by system administrators creating home file systems for themselves that are larger than the average user's file system.

For more information about controlling root login, see System Configuration for a CAPP/EAL4+ System.

Root account should be protected from remote exploits as much as possible (no direct remote login other then ssh with certificate, etc).

Secure  vs unsecure terminals

Most versions of Unix allow you to configure certain terminals so that users can't log in as the superuser from the login  : prompt. Anyone who wishes to have superuser privileges must first log in as himself and then use su to root. This feature makes tracking who is using the root account easier Network virtual terminals should not be listed as secure to prevent users from logging into the root account remotely using telnet . The Secure Shell server ignores the terminal security attribute, but it has its own directive (PermitRootLogin in sshd_config ) that controls whether users may log in as  root remotely.

On System V-derived systems, terminal security is specified in the file /etc/securetty . In general, most Unix systems today are configured so that the superuser can log in with the  root account on the system console, but not on other terminals. Even if your system allows users to log directly into the root account, we recommend that you institute rules that require users to first log into their own accounts and then use the

• The /etc/securetty file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles(vtys).
• Linux can be configured in BSD-style to provide additional protection against normal users trying to su to root That is accomplished by granting only members of the group "wheel" the ability to switch to root.

Because every UNIX system has an account named root , this account is often a starting point for people who try to break into a system by guessing passwords. One way to decrease the chance of this is to restrict logins from all but physically guarded terminals. If a terminal is marked as restricted, the superuser cannot log into that terminal from the login: prompt. (However, a legitimate user who knows the superuser password can still use the su command on that terminal after first logging in.)

On a SVR4 machine, you can restrict the ability of users to log in to the root account from any terminal other than the console. You accomplish this by editing the file /etc/default/loginand inserting the line:

CONSOLE=/dev/console

This line prevents anyone from logging in as root on any terminal other than the console. If the console is not safe, you may set this to the pathname of a nonexistent terminal.

Some older Berkeley-derived versions of UNIX allow you to declare terminal lines and network ports as either secure or not secure . You declare a terminal secure by appending the word "secure" to the terminal's definition in the file /etc/ttys

In this example taken from a /etc/ttys file, terminal tty01 is secure and terminal tty02 is not. This means that root can log into terminal tty01 but not tty02 .

Note that after changing the /etc/ttys file, you may need to send out a signal to initialize before the changes will take effect. On a BSD-derived system, run:

kill -1 1

Other systems vary, so check your own system's documentation.

You should carefully consider which terminals are declared secure. Terminals in public areas should also not be declared secure. Being "not secure" does not prevent a person from executing commands as the superuser: it simply forces users to log in as themselves and then use the su command to become root . This method adds an extra layer of protection and accounting.

On the other hand, if your computer has a terminal in a special machine room, you may wish to make this terminal secure so you can quickly use it to log into the superuser account without having first to log into your own account.

NOTE: Many versions of UNIX require that you type the superuser password when booting in single-user mode if the console is not listed as "secure" in the /etc/ttys file. Obviously, if you do not mark your console "secure," you enhance your system's security.

Spoofed Logins

Consider the case where we approach a terminal in multi-terminal environment (like used to be common at universities) and wish to login to the system. What if someone has left a spoof login running in his terminal session. If the spoof is carefully programmed you will not be able to tell the difference until the damage is done. Such problem with the programs that mimic  the login program behavior are common to all operating systems. In Windows environment where login are typically performed in GUI environment vendors produce complex animated pictures that make it more difficult to write a spoof.

In any case if you are not using one-time passwords or tokens, this way you can give an intruder access to your account.

AIX can be configured to recognize a special signal from real terminals (including workstation consoles) for this purpose. When the signal (usually a BREAK, or some sequence of control characters) is received by the low-level terminal driver, the driver sends an unstoppable signal to all processes still connected to the terminal, that terminates them. Thereafter, a new session is started and the user can be assured that the next prompt for a login is from the real system software.

For this mechanism to work, you should access real terminal: networked connection can still be intercepted and spoofed.

Red Hat Administrative Controls

Here is a long quote from Red Hat document Administrative Controlswhich explains issues more or less well:

Allowing Root Access

If the users within an organization are a trusted, computer-savvy group, then allowing them root access may not be an issue. Allowing root access by users means that minor activities, like adding devices or configuring network interfaces, can be handled by the individual users, leaving system administrators free to deal with network security and other important issues.

On the other hand, giving root access to individual users can lead to the following issues:

• Machine Misconfiguration— Users with root access can misconfigure their machines and require assistance or worse, open up security holes without knowing it.
• Running Insecure Services— Users with root access may run insecure servers on their machine, such as FTP or Telnet, potentially putting usernames and passwords at risk as they pass over the network in the clear.
• Running Email Attachments As Root— Although rare, email viruses that affect Linux do exist. The only time they are a threat, however, is when they are run by the root user.

4.4.2. Disallowing Root Access

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret and access to runlevel one or single user mode should be disallowed through boot loader password protection (refer to Section 4.2.2 Boot Loader Passwordsfor more on this topic.)

Table 4-1shows ways an administrator can further ensure that root logins are disallowed:

Method	Description	Effects	Does Not Affect
Changing the root shell.	Edit the /etc/passwd  file and change the shell from /bin/bash  to /sbin/nologin  .	Prevents access to the root shell and logs the attempt. The following programs are prevented from accessing the root account: login gdm kdm xdm su ssh scp sftp	Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs. The following programs are notprevented from accessing the root account: sudo FTP clients Email clients
Disabling root access via any console device (tty).	An empty /etc/securetty  file prevents root login on any devices attached to the computer.	Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account: login gdm kdm xdm Other network services that open a tty	Programs that do not log in as root, but perform administrative tasks through through setuid or other mechanisms. The following programs are notprevented from accessing the root account: su sudo ssh scp sftp
Disabling root SSH logins.	Edit the /etc/ssh/sshd_config  file and set the PermitRootLogin  parameter to no  .	Prevents root access via the OpenSSH suite of tools. The following programs are prevented from accessing the root account: ssh scp sftp	This only prevents root access to the OpenSSH suite of tools.
Use PAM to limit root access to services.	Edit the file for the target service in the /etc/pam.d/  directory. Make sure the pam_listfile.so  is required for authentication.[a]	Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account: FTP clients Email clients login gdm kdm xdm ssh scp sftp Any PAM aware services	Programs and services that are not PAM aware.
Notes: a. Refer to Section 4.4.2.4 Disabling Root Using PAMfor details.

Table 4-1. Methods of Disabling the Root Account

4.4.2.1. Disabling the Root Shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin  in the /etc/passwd  file. This prevents access to the root account through commands that require a shell, such as the su  and the ssh  commands.

 

	Important
	Programs that do not require access to the shell, such as email clients or the sudo  command, can still access the root account.

4.4.2.2. Disabling Root Logins

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty  file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous as a user can login into his machine as root via Telnet, which sends his password in plain text over the network. By default, Red Hat Enterprise Linux's /etc/securetty  file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:

echo > /etc/securetty

Warning A blank /etc/securetty  file does notprevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. 4.4.2.3. Disabling Root SSH Logins

To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file (/etc/ssh/sshd_config  ). Change the line that reads:

PermitRootLogin yes

to read as follows:

PermitRootLogin no

Disabling Root Using PAM

PAM, through the /lib/security/pam_listfile.so  module, allows great flexibility in denying specific accounts. This allows the administrator to point the module at a list of users who are not allowed to log in. Below is an example of how the module is used for the vsftpd  FTP server in the /etc/pam.d/vsftpd  PAM configuration file (the \character at the end of the first line in the following example is notnecessary if the directive is on one line):

auth   required   /lib/security/pam_listfile.so   item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

This tells PAM to consult the file /etc/vsftpd.ftpusers  and deny access to the service for any user listed. The administrator is free to change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration services, such as /etc/pam.d/pop  and /etc/pam.d/imap  for mail clients or /etc/pam.d/ssh  for SSH clients.

For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM)in the Red Hat Enterprise Linux Reference Guide.

4.4.3. Limiting Root Access

Rather than completely deny access to the root user, the administrator may want to allow access only via setuid programs, such as su  or sudo  .

4.4.3.1. The su  Command

Upon typing the su  command, the user is prompted for the root password and, after authentication, is given a root shell prompt.

Once logged in via the su  command, the user isthe root user and has absolute administrative access to the system. In addition, once a user has become root, it is possible for them to use the su  command to change to any other user on the system without being prompted for a password.

Because this program is so powerful, administrators within an organization may wish to limit who has access to the command.

One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:

usermod -G wheel <username>  

In the previous command, replace <username>with the username you want to add to the wheel  group.

To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command system-config-users  at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then select the Groups tab and click on the wheel group

Next, open the PAM configuration file for su  (/etc/pam.d/su  ) in a text editor and remove the comment [#] from the following line:

auth  required /lib/security/$ISA/pam_wheel.so use_uid

Doing this permits only members of the administrative group wheel to use the program.

Note: The root user is part of the wheelgroup by default.

NEWS CONTENTS

• 20000730 : LinuxSecurity - by Dave Wreski ( LinuxSecurity - , 07/30/2000 )

Old News ;-)

[07/30/2000] LinuxSecurity - Root Security By Dave Wreski

Keeping the superuser account secure should be a top priority for any system.

The most sought-after account on your machine is the superuser account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea.

Several tricks to avoid messing up your own box as root:

• When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: e.g., you are going to do a rm foo*.bak, instead, first do: ls foo*.bak and make sure you are going to delete the files you think you are. Using echo in place of destructive commands also works.
• Provide your users with a default alias to the /bin/rm command to ask for confirmation for deletion of files.
• Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are sure what needs to be done by root.
• The command path for the root user is very important. The command path, or the PATH environment variable, defines the location the shell searches for programs. Try and limit the command path for the root user as much as possible, and never use '.', meaning 'the current directory', in your PATH statement. Additionally, never have writable directories in your search path, as this can allow attackers to modify or place new binaries in your search path, allowing them to run as root the next time you run that command.
• Never use the rlogin/rsh/rexec (called the "r-utilities") suite of tools as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a .rhosts file for root.
• The /etc/securetty file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles (vtys). Be very careful of adding anything else to this file. You should be able to login remotely as your regular user account and then use su if you need to (hopefully over ssh or other encrypted channel), so there is no need to be able to login directly as root.
• Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type!

Recommended Links

• polishlinux.org " Root account
• Unix Account Security
• UNIX Security Checklist v2.0 - Full Version
• RootSudo - Community Ubuntu Documentation
• Sun Alert and Security Discussion - root account privileges
• Linux Tip- Tighten Up Security And Disable SSH Login For Root Account

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created: May 16, 1997; Last modified: March 12, 2019