May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Basics of SELinux

News Administration Recommended Books Recommended Links How to disable SELinux Red Hat Security Potemkin Villages of Computer Security Classic Open Source Unix Security Tools RBAC, SOX and Role Engineering in Large Organizations
Separation of Duties Unix permissions model The umask sudo Red Hat vs Solaris Tips   Humor Etc

SELinux has two major components in RHEL. There's the kernel mechanism which is enforcing  access rules which apply to processes and files. And secondly, there's file labels: every file on your system has extra labels attached to it which tie-in with those access rules. Run

ls -Z
and you'll see them.

There is a utility sestatus which shows current status of SElinux and the status that will be after reboot based on content of config files

sestatus -b

The /selinux/ Pseudo-File System

The /selinux/ pseudo-file system contains commands that are most commonly used by the kernel subsystem. This type of file system is similar to the /proc/ pseudo-file system.

In most cases, administrators and users do not need to manipulate this component compared to other SELinux files and directories.

The following example shows sample contents of the /selinux/ directory:

-rw-rw-rw- 1 root root 0 Sep 22 13:14 access
dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans
-w--- 1 root root 0 Sep 22 13:14 commit_pending_bools
-rw-rw-rw- 1 root root 0 Sep 22 13:14 context
-rw-rw-rw- 1 root root 0 Sep 22 13:14 create
-w--- 1 root root 0 Sep 22 13:14 disable
-rw-r-r- 1 root root 0 Sep 22 13:14 enforce
-rw--- 1 root root 0 Sep 22 13:14 load
-r-r-r- 1 root root 0 Sep 22 13:14 mls
-r-r-r- 1 root root 0 Sep 22 13:14 policyvers
-rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel
-rw-rw-rw- 1 root root 0 Sep 22 13:14 user

For example, running the cat command on the enforce file reveals either a 1 for enforcing mode or 0 for permissive mode.

SELinux Utilities

There are two utilities to check selinux status:

setenforce - Modifies in real-time the mode SELinux is running. By executing setenforce 1, SELinux is put in enforcing mode. By executing setenforce 0, SELinux is put in permissive mode. To actually disable SELinux, you need to either set the parameter in /etc/sysconfig/selinux or pass the parameter selinux=0 to the kernel, either in /etc/grub.conf or at boot time.

getenforce - Gets the detailed status of a system running SELinux. For example:


SELinux Configuration Files

There are two ways to configure SELinux under Red Hat Enterprise Linux: using the Security Level Configuration Tool (system-config-securitylevel), or manually editing the configuration file (/etc/sysconfig/selinux).

The /etc/sysconfig/selinux file is the primary configuration file for enabling or disabling SELinux, as well as setting which policy to enforce on the system and how to enforce it.

The /etc/sysconfig/selinux contains a symbolic link to the actual configuration file, /etc/selinux/config.

Options available:

* SELINUX=<enforcing|permissive|disabled> - Defines the top-level state of SELinux on a system.

Actions made while SELinux is disabled may cause the file system to no longer have the proper security context as defined by the policy. Running fixfiles relabel prior to enabling SELinux will relabel the file system so that SELinux works properly when enabled. For more information, refer to the fixfiles(8) manpage.

Additional white space at the end of a configuration line or as extra lines at the end of the file may cause unexpected behavior. To be safe, remove unnecessary white spaces.

SELINUXTYPE=<targeted|strict> - Specifies which policy is currently being enforced by SELinux.

1) targeted - Only targeted network daemons are protected.

2) Important Important

The following daemons are protected in the default targeted policy: dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, and syslogd. The rest of the system runs in the unconfined_t domain.

The policy files for these daemons can be found in /etc/selinux/targeted/src/policy/domains/program and are subject to change, as newer versions of Red Hat Enterprise Linux are released.

Policy enforcement for these daemons can be turned on or off, using Boolean values controlled by Security Level Configuration Tool (system-config-securitylevel). Switching a Boolean value for a targeted daemon disables the policy transition for the daemon, which prevents, for example, init from transitioning dhcpd from the unconfined_t domain to the domain specified in dhcpd.te. The domain unconfined_t allows subjects and objects with that security context to run under standard Linux security.

strict - Full SELinux protection, for all daemons. Security contexts are defined for all subjects and objects, and every single action is processed by the policy enforcement server.

The /etc/selinux/ Directory

The /etc/selinux/ directory is the primary location for all policy files as well as the main configuration file.

The following example shows sample contents of the /etc/selinux/ directory:

-rw-r-r- 1 root root 448 Sep 22 17:34 config
drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict
drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted

The two subdirectories, strict/ and targeted/, are the specific directories where the policy files of the same name (i.e., strict and targeted) are contained.

For more information on SELinux policy and policy configuration, refer to the rhel-pwg-selinux.

Top Visited
Past week
Past month


Old News ;-)

[Jun 11, 2012] Secure Linux Part 1. SELinux – history of its development, architecture and operating principles

As mentioned above, the SELinux system inherited the architecture of the security subsystem from the research operating system Flask. Flask's main feature was that it used the "least privilege" concept to grant users or applications only those access rights required to perform the requested actions. This concept is implemented using type enforcement (see Type Enforcement), thanks to which mandatory access in SELinux operates as part of the domain-type model. In this model each process subject is launched in a defined security context (domain) (that is, it has a certain access level), while all the operating system's resource objects (files, directories, sockets, and others) have a certain type (secrecy level) associated with them.

Thanks to type enforcement, SELinux's access control options significantly exceed the options offered by the basic discretionary access control model used in UNIX®-type systems. For example, SELinux can be used to strictly limit the network port number which the network server will be able to access. It can also allow individual files to be created and have data saved in them, but not to be deleted, etc. This grading of operating system objects helps restrict system and user processes using the set of access rights clearly assigned to specific resources. If any of the services controlled by SELinux is compromised, the intruder will not be able to get beyond the sandbox, which is restricted by the set of rules, even with superuser rights.

The list of rules defining permissions for allowing certain domains to access certain types is also a security policy. The security policy is applied once when the system is set up and consists of a set of text files which are loaded in the Linux kernel's memory during system start-up.

The rules are in a human-readable form and can be understood even by ordinary users. For example, in the rule shown below for the http server domain, permission is given to read some files containing the network configuration:

allow httpd_t net_conf_t:file { read getattr lock ioctl };

SELinux inherited the structure and principle for operating labels defining the security context of the operating system's objects and subjects, along with the "domain-type" model, from the Flask security subsystem. To ensure total protection, the security contexts must be defined for each object and each subject in the system. The labels come in the following form:

For example, the label for the distributed security context takes the form: system_u:object_r:httpd_exec_t. In SELinux, the user system_u is usually the default name for the system's daemons. The role object_r is assigned to system objects such as ordinary files or devices. The httpd_exec_t type is applied to the httpd file being executed, located at the address /usr/sbin/httpd. The user, role, and type elements will be discussed in more detail in the next article.

SELinux comprises five basic components:

SELinux's operation is organized as follows:

  1. The operating system subject (process) attempts to perform a certain action on a particular object (file, process, socket), which is permitted within the Linux standard discretionary security system (DAC). This launches a stream of requests to the object.
  2. Every request to perform the action with the object is intercepted by the Linux Security Modules and is transferred, along with the subject's and object's security context, to the SELinux Abstraction & Hook Logic subsystem, which is responsible for interaction with LSM.
  3. The information received from the SELinux Abstraction and Hook Logic subsystem is forwarded to the basic Policy Enforcement Server module, which is directly responsible for making the decision about allowing the subject to access the object.
  4. To receive the decision as to whether the action is allowed or prohibited, the policy enforcement server contacts the special Access Vector Cache subsystem, which most often caches the rules being used.
  5. If AVC does not contain the cached decision for the relevant policy, the request for the necessary security policy is forwarded again to the security policy database.
  6. When the security policy has been found, it is transferred to the policy server receiving the decision.
  7. If the requested action complies with the policy that has been found, the operation is permitted. Otherwise, it is prohibited and all the decision-making information is written to the SELinux log file.

As well as making the decision about allowing or prohibiting certain actions, the Policy Enforcement Server module is also responsible for carrying out auxiliary tasks such as security label management (allocation, removal).

Basics of SeLinux- Enable/Disable SeLinux

I run fedora and on *many* message boards I see the first trouble shooting idea is to turn off SELinux. What most people forget is that you can set SELinux to be permissive, so it is still turned on, and it lets you know when applications would be doing something that would be prevented. I think changing to permissive mode SELinux is more useful than turning it off as it lets you know what applications are misbehaving. I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies.

The main disadvantage of AppArmor is that it relies on file paths, not the inodes. All you need to do is be able to create a hard link in the right directory to get around it.


Permissive mode is only useful for policy development.

I wholeheartedly agree.
Step 1: Install RHEL, disable SELinux
Step 2: Install and configure your stack (apache, jboss, tomcat, mysql, whatever)
Step 3: Enable permissive mode, light up the stack, watch logs
Step 4: Tweak the rules, repeat step 3 until the logs are clean.
Step 5: Enable Enforcing Mode

You can now rest a little bit easier knowing that you have SELinux enabled. The only drawback is that you sometimes have to repeat the process as new versions of your stack are released (mysql, jboss). It's basically a monthly process.


100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) [] on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the /etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.

AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container.

I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web.

The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).

Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!


AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container.

Some time ago, I wrote a review of AppArmor [], finding that it solves problems that don't exist. Looking at your browser example, the functionality provided by AppArmor can be implemented completely by setting up a different user and setting appropriate file ACLs.

For the real problems AppArmor provides little help. Can you confine network usage of a program, meaning your internal network cannot be accessed once your browser has been hacked? No. Can you limit the syscalls a program may use, reducing the risk of successful kernel exploits? No.

As long as it stays this way, I recommend to everyone to use SELinux, even though it is much more difficult to setup and configure.


Good GUIs are a wonderful thing, but I want to emphasize that SELinux isn't really all that difficult to begin with. High quality SELinux rules shipped with solid distributions such as RHEL 5 eliminate many of the problems that early adopters faced; indeed, that's more or less the subject of this article.

Many people (such as myself) consider SELinux much less of a "patch job" than AppArmor. For instance, with AppArmor security attributes are not stored with the filesystem inodes, but are specified according to path name. That might simplify AppArmor's implementation a bit, but consider what happens to the security policy when you have two different path names hard linked to the same inode...

Those of us who are partial to SELinux's implementation of mandatory access controls are thrilled to see the strides that Red Hat has made in their latest enterprise release.


The problem in using a selinux system is when most of the software on the system is custom written or custom configured. Although I believe that the using the common combinations of web servers and database servers are easy to combine now, I can easily imagine wanting my web application to do things that are prohibited by policy. Customizing selinux looks somewhat challenging. If you just run a standard mail server or something it is probably great.

Everybody says that app-armor sucks with hard links, but I just don't see it. If your configuration looks like

allow all
deny read,write /root/mysecretfile

then you have a problem with hard links, but it isn't relevant. In that case you have already decided to try to solve the impossible problem of listing every important file on the system. Anyone interested in security would write:

deny all
allow read /etc/daemon.conf
allow read,write /var/daemon/data

Then I don't have to attempt to list all the secure files on the system. All I have to do is decide what I want to grant the daemon access to. If there is a hard link to /etc/daemon.conf, the program can't read it and shouldn't be trying to read it anyway.

Storing the labels in the filesystem only works if you are the distribution maintainer. If all the programs that create a particular kind of file don't agree on the label, the on-disk labels can get messed up. The simple config file in app-armor allows easy auditing.

That said, I like the possibility of securing dbus and X with the same framework as the filesystem. I'm hoping that we will see a document file access daemon for linux that allows the user to securely load and save files from a sandboxed firefox or openoffice process. Until selinux gets used for this type of desktop security instead of just network daemon security, the added power of selinux is mostly useless.


It can save a system from being compromised due to other services which are either weaker, or poorly configured. Taking some time to get SELinux working properly in ones production environment (if that system is important) is more than worth the time it takes to read up on it. Being a lazy sys admin rarely pays off in the long run.


But it all really boils down to your needs.

For example, consider the typical LAMP server (linux + apache + mysql + php) that hosts a web application. What does it need to protect ? It needs to protect the database with all the user data, the publicly accessible html documents and php scripts and possibly the log files.

You may also argue that it needs to protect the overall system from compromises involving using the system as a zombie or irc server etc. but in that situation a well managed server could simply have the software reinstalled. If the admins are competent and have access to spare servers they could configure the replacement machine and do a swap without incurring any downtime at all.

In this situation SE Linux might just be total overkill. The extra paranoid could have the publicly accessible html docs + php scripts on a read-only partition. This is a production environment we're talking about so the need to upload new documents will only be when upgrading software versions. If the web application allows users to upload data then that will need to be handled separately. A cron job could change file permissions on newly updated documents so apache no longer has write access. The log files can be moved to a separate location once per day when they're rotated where apache (or any other services) don't have access to them. MySQL can run chrooted, only bind to and the database files can only have read/write access from the mysql user. Daily, or even hourly, backups of the database to read-only media can be implemented. This is on top of running an intrusion detection system, installing security updates asap, and doing all of your other post-install locking down before the network cable is even plugged in to the machine (setting up your ssh keys, firewalls, uninstalling unnecessary software - including compilers - and obviously unused daemons and anything else the paranoid admin does before the machine goes live etc.)

We're already talking about way more security than most LAMP based servers out there.

I agree that the setup could still benefit from SE Linux, particularly for the database since it's still the weakest link and one of the areas in the most need of protection. MySQL needs to read/write to the database on a regular basis and so you need to allow write access to the data files, trust your software, trust your mysql binaries (all binary files and static config files can be on read-only partitions) and nothing is preventing a root process from changing the file permissions or corrupting the data. However, for most people this setup would be more than adequate and SE Linux would be total overkill.


The short version: it's very good. But a huge pain in the ass.

The slightly longer version: IPtables is about network access, firewalls, et cetera. SELinux is about ensuring the integrity and access rights of software on your system. It's designed to prevent, say, one process on your machine from overwriting a file it should be able to. There's a pretty good explanation of exactly what it buys you here []. (Warning: government site. They're watching youuuuuu!)

The problem with SELinux is that up until recently it has been a royal pain in the ass to configure. You'd go, "Sure, this sounds like a good idea", turn it on, and then curse it roundly when you tried updating MySQL from the version that ships with RHEL to the most recent supported release from MySQL. As a result, most folks just turned it off - they figured it wasn't worth the hassle.

RHEL 5 apparently includes tools (see the article) for figuring out what's wrong with your SELinux configuration. Definitely worth looking into. But if you're not concerned with validating application integrity on your home box... and let's face it, it's a home box... probably not worth it for you until it becomes dead simple.


Ignoring for now that nowhere in the article does he claim that SELinux provides or is required for "100% security", there's no such damn thing. Unless you pull out the power cord, of course.

Yes, we disable SELinux at our shop. As the article mentions, it's a pain in the ass, and the tools to manage it are not mature enough. If all you have is RHEL, and you have nothing else to do, you can look at configuring it. If you have a bunch of corporate mucky-mucks breathing down your neck, and you have to get the latest version of GnuWhatever compiled for 5 different OSs, there's no time to deal with this nonsense.

SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability, and right now, SELinux is just above yanking the power cord.


I've never once hit an SE Linux problem when running the stuff shipped with Fedora Core 6 and Fedora 7.

Stuff can get painful if you go grabbing 3rd-party crap from proprietary developers without neither a clue nor a care.

Even there though, the popular stuff has already been figured out. For example, suppose you want acroread or flash or vmware. Use google, and search for the stuff being spewed into the log. Skip past the idiots who just disable SE Linux; it may help to add "chcon" (an SE Linux command that fixes many such problems) to your google query.

Typically you find instructions for some "chcon -t foo_t /usr/lib/" command, often needed because the app developers were total idiots who couldn't figure out how to run gcc correctly. Run that and be happy.

(not that you should trust 3rd-party binaries to be free of malware, but hey I understand...)


SELinux probably works just great for what it was designed for - NSA top-secret systems. There's always a tradeoff between security and usability

If it's for a webserver/ftpserver/mailserver with ssh access it's pretty trivial to set up and use. If it's for something running a commercial *nix app that uses a dozen ports for weird undocumented stuff plus NFS disk access via amd it then becomes a pain.

selinux prevents login

I set selinux to enforcing and was not able to login. I booted to a live CD and, turned selinux off, and was able to login. In the selinux troubleshooter it shows:

SELinux is preventing /usr/sbin/gdm-binary (hotplug_t) "entrypoint" access to /etc/X11/xinit/Xsession (bin_t).


SELinux is preventing access to files with the label, file_t.

As far as I know, I did not change anything to create this problem. How can I correct these so that I can use enforcing mode? I'm using CentOS 5.1.

Also, let me know of any good resources for learning SELinux for Red Hat system administration. Everything I've seen is very conceptual, not very practical. At the Red Hat site they mostly say, "take the class"!

Steve Riley is offline Reply With Quote

Do you have the selinux-polgengui command installed? If so, just run it to change your policy as needed.

Do you have the system-cofig-selinux command installed? If so, run and see if that can help.

If you have neither of those tools, see if you can find them is the CentOS repositories.

Of course, if you can't log in, you system is very secure.


Although SELinux is a step in the right direction it's still basically a system of ACLs. It still suffers from the problem of the confused deputy []. I think proponents of object-capability based security are correct in their thinking. Some interesting stuff going on in this respect is the E programing language [].


Well actually you don't even need SE Linux.

First of all, don't make the compiler have setuid-like rights and don't give it arbitrary write control over a home directory. That was pure idiocy.

For ages, UNIX-like systems have used setgid (not setuid) to solve this for game high-score files. It does allow a bug in the game (an exploit perhaps) to corrupt the files, but your favored solution doesn't fix that either. Linux adds append-only files, which might be desirable for the compiler log example.

SE Linux is overkill, but we can certainly use it as an alternative to setgid. Make the file world writable. Invent an SE Linux type for it, such as fort_stat_t. Invent an SE Linux role for the compiler, such as fort_r. Mark the files appropriately. Define SE Linux policy such that processes in the fort_r role can only write to files with type fort_stat_t or with the type you use for home directories. Also define SE Linux policy such that nothing else may write to files that have type fort_stat_t. at master · lfit-itpol

SELinux on the workstation

If you are using a distribution that comes bundled with SELinux (such as Fedora), here are some recommendation of how to make the best use of it to maximize your workstation security.


  • Make sure SELinux is enforcing on your workstation (ESSENTIAL)
  • Never blindly run audit2allow -M, always check (ESSENTIAL)
  • Never setenforce 0 (NICE)
  • Switch your account to SELinux user staff_u (NICE)


SELinux is a Mandatory Access Controls (MAC) extension to core POSIX permissions functionality. It is mature, robust, and has come a long way since its initial roll-out. Regardless, many sysadmins to this day repeat the outdated mantra of "just turn it off."

That being said, SELinux will have limited security benefits on the workstation, as most applications you will be running as a user are going to be running unconfined. It does provide enough net benefit to warrant leaving it on, as it will likely help prevent an attacker from escalating privileges to gain root-level access via a vulnerable daemon service.

Our recommendation is to leave it on and enforcing.

Never setenforce 0

It's tempting to use setenforce 0 to flip SELinux into permissive mode on a temporary basis, but you should avoid doing that. This essentially turns off SELinux for the entire system, while what you really want is to troubleshoot a particular application or daemon.

Instead of setenforce 0 you should be using semanage permissive -a [somedomain_t] to put only that domain into permissive mode. First, find out which domain is causing troubles by running ausearch:

ausearch -ts recent -m avc

and then look for scontext= (source SELinux context) line, like so:


This tells you that the domain being denied is gpg_pinentry_t, so if you want to troubleshoot the application, you should add it to permissive domains:

semanage permissive -a gpg_pinentry_t

This will allow you to use the application and collect the rest of the AVCs, which you can then use in conjunction with audit2allow to write a local policy. Once that is done and you see no new AVC denials, you can remove that domain from permissive by running:

semanage permissive -d gpg_pinentry_t
Use your workstation as SELinux role staff_r

SELinux comes with a native implementation of roles that prohibit or grant certain privileges based on the role associated with the user account. As an administrator, you should be using the staff_r role, which will restrict access to many configuration and other security-sensitive files, unless you first perform sudo.

By default, accounts are created as unconfined_r and most applications you execute will run unconfined, without any (or with only very few) SELinux constraints. To switch your account to the staff_r role, run the following command:

usermod -Z staff_u [username]

You should log out and log back in to enable the new role, at which point if you run id -Z, you'll see:


When performing sudo, you should remember to add an extra flag to tell SELinux to transition to the "sysadmin" role. The command you want is:

sudo -i -r sysadm_r

At which point id -Z will show:


WARNING: you should be comfortable using ausearch and audit2allow before you make this switch, as it's possible some of your applications will no longer work when you're running as role staff_r. At the time of writing, the following popular applications are known to not work under staff_r without policy tweaks:

  • Chrome/Chromium
  • Skype
  • VirtualBox

To switch back to unconfined_r, run the following command:

usermod -Z unconfined_u [username]

and then log out and back in to get back into the comfort zone.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles




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-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 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 to buy a cup of coffee for authors of this site


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.

Last modified: March 12, 2019