Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Red Hat Security

Enterprise Unix Administration /Advanced Linux Administration /Red Hat Administration


Linux Security

Recommended Books

Recommended Links

Security issues


How to disable SELinux


RBAC, SOX and Role Engineering in Large Organizations
Separation of Duties Wheel Group SUID and SGID attributes Sticky attribute (sticky bit) in Unix Setgid bit in directories RPM-based integrity checking NFS Security  UID policy Root Security


Logs Security

User Private Groups Xen Fedora Red Hat vs Solaris Tips Humor Etc

Generally we can classify security measures into two broad categories.

Of course the distinctions are sometimes fuzzy as changing some static configuration settings, for example enabling TCP wrappers lead to introduction of dynamic processes.

There are at least two dozens of broad categories for typical security enhancing measures:

  1. Device and filesystem security measures
  2. Accounts security
  3. Authentication security
  4. Filesystem security
  5. Scripting security
  6. Network security issues
  7. X11 security

  8. Warnings, log and accounting issues

  9. Hardware Related Security Issues

  10. Applications security

The key components of OS security are analyzed feature by feature and then presented in integrated form with the corresponding numerical scores in the comparative security matrix.

Patching process quality

Linux patching process quality is noticeably worse then on Solaris and access to patches requires maintenance contact. Patches are distributed as updated packages and may involve updating the version of the software although enterprise Linux distributions like Red Hat and Suse are trying to do necessary work to avoid that.

The number of Exploits and Hacking Attacks Statistics

According the U.S. Government’s database of computer security vulnerabilities maintained by the National Institute of Standards and Technology ( as of April 15, 2004, there have been more High Severity (remotely exploitable) vulnerabilities found in the Linux operating system than in Microsoft Windows. This count removes duplicate reports of the same vulnerability against multiple versions of Linux or Windows. The CERT  report claims that security alerts for open source  and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products. NewsFactor Network - - Study Linux' Security Problems Outstrip Microsoft's

An analysis of hacker attacks on online servers in January by security consultancy mi2g found that Linux servers were the most frequently rooted, accounting for 13,654 successful attacks, or 80%t of the survey total. Windows ran a distant second with 2,005 attacks. A more specific analysis of government servers also found Linux more susceptible, accounting for 57% of all breaches. In a similar analysis last year, Windows proved far more vulnerable, with 51% of successful attacks on government servers made on some version of the Microsoft operating system.

However, the rise in successful attacks probably to a large extent reflects a lack of training and deployment expertise rather than inherent security problems in Linux.

Process security and virtualization

Linux currently does not have process protection/virtualization capabilities that are equivalent to Solaris zones or AIX partitions.  There are some attempts to replicate the capabilities of BSD jails but they are still in beta.

Security Education

The number of books devote to Linux security is considerable and by an order of magnitude surpass the number of Solaris books. Red Hat offers four security-related training courses (approximately the same as Sun for Solaris). We judge that in area Linux surpass all other Unixes and trails only Windows.

Security Certification

Most security certification specialists consider Linux less secure that top proprietary Unixes (AIX and Solaris) and that requires running Linux in a special way to augment security (deeper hardening) to compensate for this.

Many people are under the misconception that since Linux has been evaluated under the Common Criteria for IT Security Evaluation (ISO Standard 15408) that Linux must be secure. But here are the facts: Linux has been certified to EAL 3+ and EAL 4 under the Common Criteria. Those are pretty basic certification that tells not much about real-world level of security of the OS. By comparison, Windows has been also certified to EAL 4. Both AIX and Trusted Solaris are capable reaching EAL 7 certification. 

The Common Criteria standard states: “EAL 4 is the highest level at which it is likely to be economically feasible to retrofit an existing product line.” This means that if a product was not originally designed for security, it will probably never exceed EAL 4. And as we all know Security was not a focus of the original design of Linux.

Another widespread misconception that the NSA is going to solve Linux’s security problems with its Security Enhanced Linux (SELinux). But this is an urban legend.   Here are a few excerpts (

Another security problem is created by the GNU General Public License (GPL) under which Linux is licensed. GPL Section 2b (emphasis added):

“You must cause any work that you distribute or publish, that in whole or in part contains or is derived from [Linux] or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.”

That is both a legal problem (due to SCO lawsuit and potential patent-infringement lawsuits) and a cultural problem that can be classified as an implicit threat to the security of any software-based intellectual property developed on Linux.  It is recommended to acquire Linux only from the vendors that provide indemnification against legal threats.

Hardware-related security issues

Linux run on two types of hardware Classic Intel x86 architecture and EM64T-based CPUs (Intel Nocona or AMD Opteron). EMT64T is a 64 bit extension of classic Intel architecture by AMD also adopted by Intel. Generally hardware cost is the most important potential saving factor in deploying Linux and Opteron architecture is slightly more expensive. But is also slightly more secure, as if the operating system is configured to operate in 64 bit mode it is less susceptible to 32-bit oriented exploits. The latter represent about 90% of all exploits (hackers really test their code on 64 bit systems).

32 bit Intel hardware is the most hacked hardware in existence and is widely available to hackers of any country on the globe. By just switching to 64-bit hardware we can somewhat decrease security risks. The most damaging Linux virus so far, the Slapper worm, infected 20,000 systems in 100 countries in late 2002. That pales in comparison to the most damaging Windows virus, MyDoom and its variants, which infected several million computers in three weeks.  But there are orders-of-magnitude more Windows machines deployed.

By just switching to 64-bit hardware we can somewhat decrease hardware-related security risks.

Top Visited
Past week
Past month


Old News ;-)

[Jun 01, 2017] CVE-2017-1000367 Bug in sudos get_process_ttyname. Most linux distributions are affected

Jun 01, 2017 |

There is a serious vulnerability in sudo command that grants root access to anyone with a shell account. It works on SELinux enabled systems such as CentOS/RHEL and others too. A local user with privileges to execute commands via sudo could use this flaw to escalate their privileges to root. Patch your system as soon as possible.

It was discovered that Sudo did not properly parse the contents of /proc/[pid]/stat when attempting to determine its controlling tty. A local attacker in some configurations could possibly use this to overwrite any file on the filesystem, bypassing intended permissions or gain root shell.

... ... ...

A list of affected Linux distro
  1. Red Hat Enterprise Linux 6 (sudo)
  2. Red Hat Enterprise Linux 7 (sudo)
  3. Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
  4. Oracle Enterprise Linux 6
  5. Oracle Enterprise Linux 7
  6. Oracle Enterprise Linux Server 5
  7. CentOS Linux 6 (sudo)
  8. CentOS Linux 7 (sudo)
  9. Debian wheezy
  10. Debian jessie
  11. Debian stretch
  12. Debian sid
  13. Ubuntu 17.04
  14. Ubuntu 16.10
  15. Ubuntu 16.04 LTS
  16. Ubuntu 14.04 LTS
  17. SUSE Linux Enterprise Software Development Kit 12-SP2
  18. SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
  19. SUSE Linux Enterprise Server 12-SP2
  20. SUSE Linux Enterprise Desktop 12-SP2
  21. OpenSuse, Slackware, and Gentoo Linux

[Feb 11, 2015] GHOST: glibc vulnerability (CVE-2015-0235)

First of all this is kind of system error that is not easy to exploit. You need to locate the vulnerable functions in core image and be able to overwrite them via call (length of which any reasonable programmer will check). So whether this vulnerability is exploitable or not for applications that we are running is an open question.

In any case most installed systems are theoretically vilnerable. Practically too if they are running applications that do not check length for such system calls.

Only recently patched systems with glibc-2.11.3-17.74.13.x86_64 and above are not vulnerable.

[Oct 03, 2014] Everything you need to know about the Shellshock Bash bug

September 25, 2014 |
Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.

To set the scene, let me share some content from Robert Graham's blog post who has been doing some excellent analysis on this. Imagine an HTTP request like this:

target =
port = 80
banners = true
http-user-agent = shellshock-scan (
http-header = Cookie:() { :; }; ping -c 3
http-header = Host:() { :; }; ping -c 3
http-header = Referer:() { :; }; ping -c 3

Which, when issued against a range of vulnerable IP addresses, results in this:

[Oct 03, 2014] Shellshock (software bug)

Analysis of the source code history of Bash shows that the vulnerabilities had existed undiscovered since approximately version 1.13 in 1992.[4] The maintainers of the Bash source code have difficulty pinpointing the time of introduction due to the lack of comprehensive changelogs.[1]

In Unix-based operating systems, and in other operating systems that Bash supports, each running program has its own list of name/value pairs called environment variables. When one program starts another program, it provides an initial list of environment variables for the new program.[14] Separately from these, Bash also maintains an internal list of functions, which are named scripts that can be executed from within the program.[15] Since Bash operates both as a command interpreter and as a command, it is possible to execute Bash from within itself. When this happens, the original instance can export environment variables and function definitions into the new instance.[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions. It performs this conversion by creating a fragment of code from the value and executing it, thereby creating the function "on-the-fly", but affected versions do not verify that the fragment is a valid function definition.[17] Therefore, given the opportunity to execute Bash with a chosen value in its environment variable list, an attacker can execute arbitrary commands or exploit other bugs that may exist in Bash's command interpreter.

The name "shellshock" is attributed[by whom?][not in citation given] to Andreas Lindh from a tweet on 24 September 2014.[18][non-primary source needed]

On October 1st, Zalewski released details of the final bugs, and confirmed that Florian's patch does indeed prevent them. Zalewski says fixed

CGI-based web server attack

When a web server uses the Common Gateway Interface (CGI) to handle a document request, it passes various details of the request to a handler program in the environment variable list. For example, the variable HTTP_USER_AGENT has a value that, in normal usage, identifies the program sending the request. If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above. This provides a means for an attacker to trigger the Shellshock vulnerability with a specially crafted server request.[4] The security documentation for the widely used Apache web server states: "CGI scripts can ... be extremely dangerous if they are not carefully checked."[20] and other methods of handling web server requests are often used. There are a number of online services which attempt to test the vulnerability against web servers exposed to the Internet.[citation needed]

SSH server example

OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running an unrestricted command shell. The fixed command is executed even if the user specified that another command should be run; in that case the original command is put into the environment variable "SSH_ORIGINAL_COMMAND". When the forced command is run in a Bash shell (if the user's shell is set to Bash), the Bash shell will parse the SSH_ORIGINAL_COMMAND environment variable on start-up, and run the commands embedded in it. The user has used their restricted shell access to gain unrestricted shell access, using the Shellshock bug.[21]

DHCP example

Some DHCP clients can also pass commands to Bash; a vulnerable system could be attacked when connecting to an open Wi-Fi network. A DHCP client typically requests and gets an IP address from a DHCP server, but it can also be provided a series of additional options. A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.[9]

Note of offline system vulnerability

The bug can potentially affect machines that are not directly connected to the Internet when performing offline processing, which involves the use of Bash.[citation needed]

Initial report (CVE-2014-6271)

This original form of the vulnerability involves a specially crafted environment variable containing an exported function definition, followed by arbitrary commands. Bash incorrectly executes the trailing commands when it imports the function.[22] The vulnerability can be tested with the following command:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

In systems affected by the vulnerability, the above commands will display the word "vulnerable" as a result of Bash executing the command "echo vulnerable", which was embedded into the specially crafted environment variable named "x".[23][24]

There was an initial report of the bug made to the maintainers of Bash (Report# CVE-2014-6271). The bug was corrected with a patch to the program. However, after the release of the patch there were subsequent reports of different, yet related vulnerabilities. On 26 September 2014, two open-source contributors, David A. Wheeler and Norihiro Tanaka, noted that there were additional issues, even after patching systems using the most recently available patches. In an email addressed to the oss-sec list and the bash bug list, Wheeler wrote: "This patch just continues the 'whack-a-mole' job of fixing parsing errors that began with the first patch. Bash's parser is certain [to] have many many many other vulnerabilities".[25]
On 27 September 2014, Michal Zalewski announced his discovery of several other Bash vulnerabilities,[26] one based upon the fact that Bash is typically compiled without address space layout randomization.[27] Zalewski also strongly encouraged all concerned to immediately apply a patch made available by Florian Weimer.[26][27]


CVE-2014-6277 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[26][27][28][29]

This causes a segfault.

() { x() { _; }; x() { _; } <<a; }


CVE-2014-6278 relates to the parsing of function definitions in environment variables by Bash. It was discovered by Michał Zalewski.[30][29]

() { _; } >_[$($())] { echo hi mom; id; }


On the same day the bug was published, Tavis Ormandy discovered a related bug which was assigned the CVE identifier CVE-2014-7169.[21] Official and distributed patches for this began releasing on 26 September 2014.[citation needed] Demonstrated in the following code:

env X='() { (a)=>\' sh -c "echo date"; cat echo

which would trigger a bug in Bash to execute the command "date" unintentionally. This would become CVE-2014-7169.[21]

Testing example

Here is an example of a system that has a patch for CVE-2014-6271 but not CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

The patched system displays the same error, notifying the user that CVE-2014-6271 has been prevented. However, the attack causes the writing of a file named 'echo', into the working directory, containing the result of the 'date' call. The existence of this issue resulted in the creation of CVE-2014-7169 and the release patches for several systems.

A system patched for both CVE-2014-6271 and CVE-2014-7169 will simply echo the word "date" and the file "echo" will not be created.

$ X='() { (a)=>\' bash -c "echo date"
$ cat echo
cat: echo: No such file or directory


CVE-2014-7186 relates to an out-of-bounds memory access error in the Bash parser code.[31] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "<<EOF" declarations:

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' ||
echo "CVE-2014-7186 vulnerable, redir_stack"
A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack".


CVE-2014-7187 relates to an off-by-one error, allowing out-of-bounds memory access, in the Bash parser code.[32] While working on patching Shellshock, Red Hat researcher Florian Weimer found this bug.[23]

Testing example

Here is an example of the vulnerability, which leverages the use of multiple "done" declarations:

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash ||
echo "CVE-2014-7187 vulnerable, word_lineno"
A vulnerable system will echo the text "CVE-2014-7187 vulnerable, word_lineno".

Frequently Asked Questions about the Shellshock Bash flaws

Sep 26, 2014 |

Why are there four CVE assignments?

The original flaw in Bash was assigned CVE-2014-6271. Shortly after that issue went public a researcher found a similar flaw that wasn't blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. It's possible that other issues will be found in the future and assigned a CVE designator even if they are blocked by the existing patches.

... ... ...

Why is Red Hat using a different patch then others?

Our patch addresses the CVE-2014-7169 issue in a much better way than the upstream patch, we wanted to make sure the issue was properly dealt with.
I have deployed web application filters to block CVE-2014-6271. Are these filters also effective against the subsequent flaws?

If configured properly and applied to all relevant places, the "() {" signature will work against these additional flaws.

Does SELinux help protect against this flaw?

SELinux can help reduce the impact of some of the exploits for this issue. SELinux guru Dan Walsh has written about this in depth in his blog.

Are you aware of any new ways to exploit this issue?

Within a few hours of the first issue being public (CVE-2014-6271), various exploits were seen live, they attacked the services we identified at risk in our first post:

We did not see any exploits which were targeted at servers which had the first issue fixed, but were affected by the second issue. We are currently not aware of any exploits which target bash packages which have both CVE patches applied.

Why wasn't this flaw noticed sooner?

The flaws in Bash were in a quite obscure feature that was rarely used; it is not surprising that this code had not been given much attention. When the first flaw was discovered it was reported responsibly to vendors who worked over a period of under 2 weeks to address the issue.

This entry was posted in Vulnerabilities and tagged bash, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, shellshocked by Huzaifa Sidhpurwala. Bookmark the permalink.

Update 2014-09-25 16:00 UTC

Red Hat is aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

We are working on patches in conjunction with the upstream developers as a critical priority. For details on a workaround, please see the knowledgebase article.

Red Hat advises customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271 and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.

Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.

In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)

Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

Like "real" programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 this is a test

The patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:

 $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 this is a test

We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.

Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.

We have additional information regarding specific Red Hat products affected by this issue that can be found at

Information on CentOS can be found at


[Sep 29, 2014] Shellshock: How to protect your Unix, Linux and Mac servers By Steven J. Vaughan-Nichols

Fortunately, all the major Linux vendors quickly issued patches, including Debian, Ubuntu, Suse and Red Hat.

The only thing you have to fear with Shellshock, the Unix/Linux Bash security hole, is fear itself. Yes, Shellshock can serve as a highway for worms and malware to hit your Unix, Linux, and Mac servers, but you can defend against it.

The real and present danger is for servers. According to the National Institute of Standards (NIST), Shellshock scores a perfect 10 for potential impact and exploitability. Red Hat reports that the most common attack vectors are:

So much for Red Hat's thoughts. Of these, the Web servers and SSH are the ones that worry me the most. The DHCP client is also troublesome, especially if, as it the case with small businesses, your external router doubles as your Internet gateway and DHCP server.

Of these, Web server attacks seem to be the most common by far. As Florian Weimer, a Red Hat security engineer, wrote: "HTTP requests to CGI scripts have been identified as the major attack vector." Attacks are being made against systems running both Linux and Mac OS X.

Jaime Blasco, labs director at AlienVault, a security management services company, ran a honeypot looking for attackers and found "several machines trying to exploit the Bash vulnerability. The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system."

Other security researchers have found that the malware is the usual sort. They typically try to plant distributed denial of service (DDoS) IRC bots and attempt to guess system logins and passwords using a list of poor passwords such as 'root', 'admin', 'user', 'login', and '123456.'

So, how do you know if your servers can be attacked? First, you need to check to see if you're running a vulnerable version of Bash. To do that, run the following command from a Bash shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you get the result:

vulnerable this is a test

Bad news, your version of Bash can be hacked. If you see:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test

You're good. Well, to be more exact, you're as protected as you can be at the moment.

Updated information on the bash fixes.
26 Sep 2014 |

We have fixed the critical issue CVE-2014-6271 ( with updates for all supported and LTSS code streams.

SLES 10 SP3 LTSS, SP4 LTSS, SLES 11 SP1 LTSS, SLES 11 SP2 LTSS, SLES 11 SP3, openSUSE 12.3, 13.1.

The issue CVE-2014-7169 ( is less severe (no trivial code execution) but will also receive fixes for above. As more patches are under discussions around the bash parser, we will wait some days to collect them to avoid a third bash update.

[Sep 02, 2010] Guide to the Secure Configuration of Red Hat Enterprise Linux 5

NSA has developed and distributed configuration guidance for Red Hat Enterprise Linux 5 that is currently being used throughout the government and by numerous entities as a security baseline for their Red Hat Enterprise Linux 5 systems. See also Hardening Tips for the Red Hat Enterprise Linux 5

[Feb 24, 2009] Linux Security Securing and Hardening Linux Production Systems (Linux Security Cookbook - HOWTO - Guide)

Good, carefully written guide. highly recommended

This Linux Security HOWTO is intended for a technical audience, Linux system administrators, and security people in corporations and organizations that have to use commercial Linux distributions for their production environment. If you are a Linux expert then you may find familiar material here, but you will have difficulties to find documentation on various topics like restricting su access to system and shared accounts only as covered in this article, see Restricting su Access to System and Shared Accounts.
If you need to make Linux production systems compliant with various audit requirements, then this article should offer a good baseline and starting point. The main objective of this Linux Security guide is to discuss basic Linux security requirements including account policies for production systems that are being audited. This document covers various system services like SSH which are usually enabled and required on all Linux production servers. But it does not cover services or applications like Apache, Samba etc., since these applications/services are usually not needed across all Linux servers and should therefore not be installed on all systems. In fact, these applications warrant their own security HOWTO. Also, this article does not cover security features that require kernel patching. This is not an option for most companies due to vendor support issues.

This Linux Security Cookbook has been tested on Red Hat Linux but should also be applicable to many other Linux distributions like Novell SUSE.

[Feb 18, 2009] Sparks' Fedora Project Journal Hardening Guides for RHEL 5

Just noticed where the NSA has made available two documents on hardening and secure configuration of RHEL 5. Should be interesting to read through the documents to see what they recommend. I wonder how much of this can be passed on to the Fedora community.

Almost all of it can be passed on. There are great tips in there - kernel sysctl's tuning, SSH hardening, disabling coredumps, using AIDE, and disabling SUID on unneeded binaries, just to name a few. I found it a really good read,

[Aug 23, 2008] OpenSSH blacklist script

That's sad -- RHN was compromised due and some trojanized OpenSSH packages were uploaded.
22nd August 2008

Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.

In connection with the incident, the intruder was able to get a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only) signed. As a precautionary measure, we are releasing an updated version of these packages and have published a list of the tampered packages and how to detect them.

To reiterate, our processes and efforts to date indicate that packages obtained by Red Hat Enterprise Linux subscribers via Red Hat Network are not at risk.

We have provided a shell script which lists the affected packages and can verify that none of them are installed on a system:

The script has a detached GPG signature from the Red Hat Security Response Team (key) so you can verify its integrity:

This script can be executed either as a non-root user or as root. To execute the script after downloading it and saving it to your system, run the command:

   bash ./

If the script output includes any lines beginning with "ALERT" then a tampered package has been installed on the system. Otherwise, if no tampered packages were found, the script should produce only a single line of output beginning with the word "PASS", as shown below:

   bash ./
   PASS: no suspect packages were found on this system

The script can also check a set of packages by passing it a list of source or binary RPM filenames. In this mode, a "PASS" or "ALERT" line will be printed for each filename passed; for example:

   bash ./ openssh-4.3p2-16.el5.i386.rpm
   PASS: signature of package "openssh-4.3p2-16.el5.i386.rpm" not on blacklist

Red Hat customers who discover any tampered packages, need help with running this script, or have any questions should log into the Red Hat support website and file a support ticket, call their local support center, or contact their Technical Account Manager.

[May 28, 2004] Linux Today - Linux Vs. Windows CeBIT Panelists Weigh The OS

Linux Vs. Windows: CeBIT Panelists Weigh The OS
May 28, 2004, 21 :15 UTC (6 Talkback[s]) (3388 reads)
(Other stories by Jacqueline Emigh)

By Jacqueline Emigh
Linux Today Correspondent

Do Linux security exploits really belong in the same league as Windows security holes? Are OpenOffice and its derivatives actually as good as Microsoft Office? These are just a couple of the questions debated this week by a panel of experts at the CeBIT America show in New York City.

Comparing Linux and Windows security amounts to a "chicken and egg" issue, according to Kathy Ivens, an author and consultant.

Given that Linux is a more secure environment, it's tough to know whether this is because Linux is "inherently more secure," or because Windows is still the more prevalent environment, Ivens said, during a panel moderated by Paul Gillin, VP of Editorial at TechTarget.

Also during the session, Nicholas Petreley, an analyst and consultant at Evans Data, contended that regardless of the numbers of exploits per platform, Windows exploits are often much more severe. Citing materials produced by Microsoft itself, Petreley said that many of the growing population of worms targeting Windows let outside hackers "completely take over" a server.

In contrast, Linux exploits are generally more limited in scope, and more likely to lend themselves to insider attacks, Petreley suggested. One Linux exploit, for instance, permits information in Firebird servers to be overwritten.

Generally speaking, though, Windows is still easier to administer, according to several of the panelists. "That's where Linux is behind, especially in directory services," Petreley observed.

Jon "Maddog" Hall, president and executive director of Linux International, pointed to third-party tools, available from vendors such as IBM and Computer Associates (CA), for managing Linux along with MVS and Unix, for example.

"In enterprise environments, that's what (you're) looking for," said Hall. Yet, he admitted, companies need to pay for such tools.

"(Administrative) controls are a lot better (in Windows)," Ivens asserted, citing printer set-up as one example.

Meanwhile, other panelists pointed to freely available Linux tools such as Samba.

What about Linux on the desktop? OpenOffice and its derivatives lack some of the features of Microsoft Office, according to Mark Minasi, a writer and consultant

Petreley, though, argued that EI (Evermore Integrated) Office, an office suite from Evermore Software, contains a similar feature set to Microsoft Office. Unlike Microsoft Office, however, EI Office doesn't allow anti-aliasing of fonts, he acknowledged, attributing this distinction to a decision by authors of the Java-based program to reduce overhead. EI Office runs on both Linux and Windows.

OpenOffice types of suites also tend to come with fewer fonts, indicated Hall. One rather obvious reason is that some font creators charge for the fonts, according to Hall.

On an overall basis, Linux applications still lack the "fit and finish" of Windows apps, Minasi charged. To gain more traction on the desktop, Linux needs a better GUI, he insisted.

Ivens, however, argued that GUIs aren't necessarily the way to go for all applications. In fact, some database and accounting apps have actually taken performance hits from the advent of the Windows GUI.

"There's no reason to have a GUI to punch in numbers," Ivens said. She harkened back to the days when the MAS 90 accounting system was at its zenith. Back then, MAS 90 was sold in Unix and DOS flavors. "My clients loved it," according to Ivens.

Ivens would also like to see fewer features in today's office suites. Microsoft Office, she quipped, seems to be evolving under an illusion in Redmond that "everyone in the world is collaborating on a single document."

Yet most users take advantage of only a small fraction of Office features, and migration to Microsoft Office 2003 has been particularly slow, Ivens observed.

In terms of third-party desktop applications, Linux is now starting to catch up with Windows, panelists generally concurred. Quicken, for instance, is now available for Linux, said Hall.

Desktop gaming, however, is one area where Linux still lags, according to Petreley. Yet with increasing improvements to game consoles such as Game Cube, more consumers are migrating from Windows-based PC games to consoles.

On the other hand, Windows doesn't necessarily hold much of an edge when it comes to ease of installation, according to the CeBIT panelists. Many users don't know how tricky Windows can be to install, since Windows still comes pre-installed on most PCs, members of the CeBIT audience were told.

Hall said that he'll be more than happy if Linux ultimately captures 30 percent of the desktop space.

"Competition is good," he declared. Hall reasoned that, as a result, no operating system -- not even Linux -- should totally dominate any market. - IBM's Linux Push

With the release of Linux version 2.6, Linux scalability has leapt to the point where it will support deployment on 32-way SMP machines. IBM sees this, rightly in my opinion, as an opportunity to sell Linux based solutions into an area of usage from which it had previously been excluded. This means big ERP, CRM and SCM implementations (using SAP, PeopleSoft et al). It also means big database implementations and big app server implementations. This is also an area where the 64-bit implementations of Linux will deliver value.

According to Adam Jollans, who is part of IBM's Linux Marketing Strategy team, the adoption of Linux is happening most quickly in Banking, Government and Retail, followed by sectors that use scientific or engineering applications (automotive, pharmaceuticals, life sciences, education etc.) This is unusual in some respects as the Banking industry is normally an early adopter of technology whereas Government is normally a late adopter, but these two sectors appear to be driving Linux adoption along with Retail.

Government qualifies as a special case, since many governments now see in Linux the possibility of stimulating a local IT software industry and are doing what they can to stimulate the growth of Linux skills. And naturally, IBM is doing what it can to associate itself with many of these initiatives, having set up competence centres in Moscow, Beijing and Romania and offering support for Linux based government initiatives wherever it can.

IBM is also active in stimulating Linux adoption among ISVs and Business Partners, offering incentives to migrate to Linux, which vary from market development funding and marketing assistance to big discounts on IBM Linux-based software. This is not so much a new initiative, as IBM has been enabling the Linux community for many years now, just a more aggressive push than before.

IBM also has many developers working on Linux and other key Open Source projects. Currently the count is at about 500, which if you think about it, represents a large on-going investment. However, there can be little doubt that IBM is getting an adequate return, and in any event it has another axe to grind.

IBM's "On Demand" initiative will be far more likely to deliver results if a single standard operating system emerges in the coming years. As far as I can tell, this looks likely to happen and it will be the horse that IBM is so clearly backing; Linux.

Linux Today - IT-Analysis Linux To Become A De Facto Standard

IBM, Hewlett-Packard and Sun Microsystems, among others, are creating an imperative. Their infrastructure initiatives, entitled respectively; On Demand, Adaptive Enterprise and N1, are all quite similar and aimed at the idea of virtualising the hardware layer. The primary reason for wanting to virtualise hardware is this; in the last five years or so companies have been buying servers in an ad hoc manner, tending to deploy them on a one server per application basis.

Consequently, they assembled server farms which turn out to have an average hardware utilization of about 20 percent. This is, of course, a waste of money and, in the long run, a management headache. However there are other imperatives, particularly the idea of being able to provide infrastructure as a service - dynamically, i.e. you pay for what you use and you get what you need when you need it.

So companies, especially large companies, are very receptive to the idea of corporate computer resource that is both managed and efficient - which is what IBM, HP and Sun are talking about. However, if you talk the talk you are also going to have to walk the walk, and right now, what can be delivered doesn't amount to wall-to-wall virtualisation - or anything like it.

So the question is: How is it ever going to be delivered - given legacy systems, existing server farms and the enormous difficulty involved in relocating applications in a heterogeneous network.

Blade technology, grid computing, automatic provisioning, SANs, NAS and so forth will play a part in this, but for it to work, and work well, it will require a standard OS - and there is only one candidate - Linux.

The easiest way to see the need for a standard OS is to consider why and how TCP/IP became a standard. It didn't happen because it was the best option or because it was purpose designed to run a world-wide network with hundreds of millions of nodes (it wasn't). It happened because it was the only reasonable choice at the time. The same is now true of Linux as regards hardware virtualisation. Irrespective of its other qualities, it is the only one that fits the bill.

It qualifies because it spans so many platforms - from small devices up to IBM's zSeries mainframe. It also qualifies because, like TCP/IP, it doesn't actually belong to anyone. It runs on most chips and is rapidly becoming the developer platform of choice. So the idea is starting to emerge that you virtualise storage by the use of SANs and NAS and you virtualise server hardware by the use of Linux - thus making it feasible to switch applications from one server to another automatically, and quickly. Within this capability you can cater for failover and make highly efficient use of resources.

This doesn't solve all the problems of virtualisation - and there are many, including legacy hardware that will never run Linux and legacy applications that will never run on Linux. But this doesn't actually matter. In the short run they'll get excluded from virtualisation and in the long run, they cease to exist.

The momentum is building and Linux is set to become the standard OS for hardware virtualisation in large networks. Other OSes may eventually have to impersonate the characteristics of Linux or move aside.

[1/6/2004] Managing Linux Security Effectively in 2004

Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates.

By Benjamin D. Thomas

This article examines the process of proper Linux security management in 2004. First, a system should be hardened and patched. Next, a security routine should be established to ensure that all new vulnerabilities are addressed. Linux security should be treated as an evolving process.


As Linux continues to gain popularity in the business world, security issues are something that cannot be ignored. In 2003, several well known Linux distributors had servers compromised. In one particular case, the vulnerability was well known in advance, but most vendors took entirely too much time to release an update. Similarly, most security problems that users face are known well in advance. As with any system, security on Linux is a process. It requires full commitment and due diligence. The secret is determining your own vulnerabilities and fixing them before anything catastrophic happens.

Although Linux security is entirely in the hands of system administrators, several improvements have been made at the kernel level. With the release of kernel version 2.6, users will now be able to take advantage of the Linux Security Module allowing greater levels of security customization, modularization, and ease of management. Another thing that has changed in the past several years is that today more of us are reliant on automated software update services. Rather than download and install patches manually, it is now easier to subscribe to a trusted source and let the system manage itself. As long as the integrity of the trusted source remains strong, automated management works flawlessly. As soon as something questionable happens, it is necessary to re-evaluate.

Solve the Problem

Addressing Linux security is like solving any problem. It must be approached with a purpose and plan. If you have been using Linux and neglecting security, it is now time to face it head on. Although the task may seems daunting in the beginning, it will soon be apparent that securing a Linux system is actually very strait forward.

In general security can be summed up into several steps. First, live by the minimum necessary rule. For example, turn off all unnecessary services, remove all programs that are not being used, and only give access when it is absolutely critical to a particular job function. Taking this simplistic approach will not only increase security, but over time will make life easier. It will eventually mean less stale-accounts to remove, less software to patch, and greater system performance.

Next, keep a software inventory of all versions used. Use this information to conduct the research necessary to ensure that all have been patched appropriately. Doing this, will greatly reduce the risk of being compromised by a known vulnerability. As simple as it may sound, doing this will make the system no longer an easy target, therefore be much less likely compromised. Unless the attacker is highly motivated highly sophisticated a hardened system will not be appealing.

Because most organizations have tens to hundreds of systems to manage, living by the minimum necessary rule, and establishing a security patch baseline is not always easy. The only way to approach Linux security is by developing a detailed plan. If server roles can be modularized, it may be much easier to determine what software is actually necessary for operation. Similarly, if multiple Web servers are on the network, they should all have the same basic set of software which again makes management easier. Planning for security, rather than trying to bolt it on after implementation is the key to success.

Setup a Routine

After a security plan is established and well underway, it also necessary to have a security routine. Security patches are released daily and your organization must have a way to deal with these. Hardening a system will only ensure a high level of security a single point in time. As time moves forward and vulnerabilities are discovered and exploits are made public, the system will become more vulnerable each day. To address this, it is necessary to monitor mailing lists, subscribe to our newsletter Linux Advisory Watch, or subscribe to an automated patch management system. When evaluating Linux distributions, it is important to take into account the frequency, timeliness, and reliability of security updates. Unfortunately, some distributions have been known to only release updates every several months in inconsistent intervals. Others are very good and release patches very soon after the vulnerability is known.

Some may wish to apply security updates daily, but it is probably more reasonable to apply them weekly. Of course, exceptions should be made for very critical updates. If production servers are going to be updated, it is advisable to first try them out in a testing environment. This is to minimize any damage that a flawed patch may cause. Also, do not forget to check the MD5 checksums of all downloaded patches. This can be done easily using the command-line tool 'md5sum.' To ensure overall system integrity, it is beneficial to a tool such as tripwire.

Being the new year, it is now the best time to establish a routine. Excuses can always be made, but now is the best time to start. Determine what is necessary to keep your systems operating securely, and pick a day each week to devote to this. Time should be spent applying security patches, reviewing logs, reviewing active user accounts, and looking for anomalies. Devoting just a little time specifically security each week can make a huge difference. It is always better to address problems before they crop up.

Concluding Remarks

Security requires both dedication and commitment. 2004 can be a good year if you expect security problems and then develop specific plans to address each of them. After the basics have been addressed, now is the time to establish a routine that will ensure security is addressed on a reoccurring basis rather than waiting for problems to surface. To maintain proper Linux security, it must be a regular part of an organization's operational maintenance. Being the beginning of a new year, it is now the perfect time to establish routines that will promote greater security. Linux is a wonderful operating system and holds a huge amount of potential. Security should not be major concern as long as it is handled properly.

Benjamin Thomas is a long time contributor to and EnGarde Secure Linux.

[Nov 15, 2002] NewsFactor Network - - Study Linux' Security Problems Outstrip Microsoft's

Open source software has surpassed Microsoft software in terms of security problems, according to an Aberdeen Group report.

"Open source software, commonly used in many versions of Linux, Unix, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report stated.

The research cited a list of advisories published by the Computer Emergency Response Team (CERT), a federally funded research and development center operated by Carnegie Mellon University.

The CERT report claims that security alerts for open source Latest News about open source and Linux software accounted for 16 out of the 29 advisories published during the first 10 months of 2002. During those same 10 months, only seven security problems were documented in Microsoft products.

Trojan Horses and Viruses

Microsoft applications have made significant progress in avoiding virus and Trojan horse problems, according to CERT. The number of such advisories peaked in 2001 at six, but none were posted during the first 10 months of 2002.

Virus and Trojan horse advisories for Unix, Linux and open source software went from one in 2001 to two in the first 10 months of 2002.

To fully understand these figures, it is important to understand CERT's criteria for issuing an advisory, Aberdeen Group research director and report co-author Eric Hemmendinger told NewsFactor.

For example, although several viruses that affect Microsoft products have been reported this year, such threats need to reach a certain severity level before CERT will issue an advisory in response to them, he said.

New Poster Child

"Obviously, the label of poster child for security glitches moved from Microsoft to the shoulders of open source and Linux product suppliers during 2002," the Aberdeen research stated.

Hemmendinger said the greater number of security vulnerabilities in open source was connected to problems with quality assurance testing. "While there are multiple distributors of open source products, there is no single entity responsible for quality assurance or for addressing security issues," he said.

Popular Misconception

Hemmendinger noted that the CERT findings run counter to what he sees as a popular misconception: that Microsoft software suffers the most security problems.

He said that network administrators trying to assess Microsoft versus open source platform strategies "need to set aside everything you've heard over the last year and look at what the numbers actually show. Perception does not match reality."

Rationale for Change

One reason for the decreased number of Microsoft security problems may be "the beginnings of an impact of efforts Microsoft has made to improve coding practices," Hemmendinger said.

He noted that not only has Microsoft made security a major push this year, "but there have been a number of things that have gone on [in Microsoft] over the last couple years reflecting that they know security matters, and that they had to pay attention to it."

Future of Open Source

Hemmendinger predicted even more security advisories will be released for open source products in the future, while the number of Microsoft security vulnerabilities will remain flat or decrease.

"The numbers lag the adoption," he said, explaining that as open source becomes more prevalent, problems -- and scrutiny of weaknesses -- will increase.

Apple Bit, Also

"Apple's products are now just as vulnerable, now that it is fielding an operating system with embedded Internet protocols and Unix utilities," the Aberdeen reported added.

According to the CERT list, security advisories affecting Apple's Latest News about Apple OS X jumped from two in 2001 to four in the first 10 months of 2002.

Linux Security Quick Reference Guide
This Quick Reference Guide is intended to provide a starting point for improving the security of your system. Contained within include references to security resources around the net, tips on securing your Linux box, and general security information.
[PDF] [PS] [A4 PS] [A4 PDF]
Linux Security Administrator's Guide
This is a document that I last made modifications to in 1998, but is still pretty relevant. Topics covered include developing a security policy, network and host security tips, process accounting, physical security, intrusion detection, files and filesystem security, encryption, kernel security, explanation of many types of exploits, links to documents on writing secure code, firewalls, and incident response. I would be very interested in hearing any comments about this document.
[HTML] [PS] [DVI] [SGML] [TEXT] Main Documentation Resource Page
This section contains documentation on how to improve the security of your Linux box, whitepapers on various security issues, newsletters, a glossary of security terms as well as publications. We've tried our best to accumulate the most relevant and up-to-date list of documentation here.
This FAQ is intended to serve as a starting point for those new to the newsgroup, but is also intended to be a survey of Linux security issues and tools. This FAQ is aimed at intermediate to experienced Linux users and is intended to not only answer specific questions, but to also facilitate further learning by providing pointers other useful security resources.

Be sure to read our interview with author Daniel Swan to learn more about this document.

Linux Security HOWTO
This document is a general overview of security issues that face the administrator of Linux systems. It covers general security philosophy and a number of specific examples of how to better secure your Linux system from intruders. Also included are pointers to security-related material and programs.
Linux Security Quick-Start Guide
This document, written by Hal Burgiss, is an introductory level document that provides the information necessary for inexperienced Linux users to secure their machine. Well-written and thorough.

Be sure to read our interview with Hal on Linux security and his document.

[HTML] [Red Hat Version]
Understanding TCP/IP
This Cisco whitepaper discusses the TCP/IP architecture and provides a basic reference model that explains TCP/IP terminology and describes the fundamental concepts underlying the TCP/IP protocol suite. Great document.
Securing Debian HOWTO
This document describes the process of securing and hardening the default Debian installation. In addition this document just gives a overview of what you can do to increase the security of your Debian GNU/Linux installation. Many parts of this HOWTO can be transferred to other distributions.
Secure Programming HOWTO
This paper provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, CGI scripts, network servers, and setuid/setgid programs. Specific guidance for C, C++, Java, Perl, Python, and Ada95 are included. See our interview with David Wheeler on
WWW Security FAQ
This is the World Wide Web Security Frequently Asked Question list (FAQ). It attempts to answer some of the most frequently asked questions relating to the security implications of running a Web server and using Web browsers.
Describes installing the BIND 9 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise.
Encryption HOWTO
This document will (eventually, more or less extensively) describe all major development activities around the Linux operating system that provide encryption features to the kernel.
Securing-Domain HOWTO
Outlines the things you will probably have to do when you want to setup a network of computers under your own domain. Covers configuration of network parameters, network services, and security settings.
This HOWTO describes how to set up a Virtual Private Network with Linux.
VPN Masquerade HOWTO
How to configure a Linux firewall to masquerade IPsec-and PPTP-based Virtual Private Network traffic, allowing you to establish a VPN connection without losing the security and flexibility of your Linux firewall's internet connection and allowing you to make available a VPN server that does not have a registered internet IP address.

Securing and Optimizing Linux: Red Hat Edition

This book addresses unanswered questions about Linux security and optimization in the marketplace. It is intended for a technical audience and discusses how to install a Red Hat Linux Server with all the necessary security and optimization for a high performance Linux-specific machine. It covers (in detail) several ways to configure security and optimization.


alt.2600 Hack FAQ

The purpose of this FAQ is to give you a general introduction to the topics covered in alt.2600 and #hack. General information on hacking, telephony, cellular communications, security resources, and a description of what alt.2600 actually is.


Recommended Links

Google matched content

Softpanorama Recommended

Top articles


rhel5-guide-i731 NSA RHEL5 Hardening guide

***** Linux Security Securing and Hardening Linux Production Systems (Linux Security Cookbook - HOWTO - Guide)

Restricting su Access to System and Shared Accounts

[PDF] Hardening Red Hat Enterprise Linux 5

Red Hat Enterprise Linux 4

Hardening a Linux Installation

Red Hat Enterprise Linux 4
Red Hat Enterprise Linux 4. Red Hat SELinux Guide. Copyright © 2005 Red Hat, Inc. ISBN: N/A. Table of Contents; Introduction to the Red Hat SELinux Guide ... enterprise/RHEL-4-Manual/selinux-guide/ - 11k

Installing and configuring OpenLDAP for RedHat Enterprise Linux 3

Installing and configuring OpenLDAP for RedHat Enterprise Linux3 ... It is highly recommended that OS level Security Hardening be applied to all LDAP ... Installing%20and%20configuring%20OpenLDAP%20for%

CERT Guides



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


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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


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


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


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 author present and former employers, SDNP or any other organization the author may be associated with. 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 Jan 2, 2005. Last modified: December 26, 2017