Conversion of Application and Adminitrative Accounts to Roles

Single Role Only - This method adds the Primary Administrator role only and is similar to the superuser model.

Suggested Roles - Three suggested roles that can be easily configured are available: Primary Administrator, System Administrator, and Operator. These roles are suitable for organizations with administrators at different levels of responsibility whose job capabilities fit the suggested roles.

Custom Roles - You can create your own roles to meet the security requirements of your organization. The new roles can be based on existing or customized rights profiles.

Decide which suggested roles are appropriate for your organization.

Review the capabilities of the suggested roles and default rights profiles. Three rights profiles are available for configuring the suggested roles:

• Primary Administrator rights profile - For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.

• System Administrator rights profile - For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts, but cannot set passwords or grant rights to other users.

• Operator rights profile - For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.

These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.

To further examine rights profiles, use the Rights tool to display the contents. You can also refer to "Contents of Rights Profiles" for a summary of some typical rights profiles. With the console tools, you can customize the roles and rights profiles that are provided to meet the needs of your organization.

Decide if any additional roles or rights profiles are appropriate for your organization.

Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC.

1. Determine which commands are needed for the new task.

2. Decide which rights profile is appropriate for this task.

   Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.

3. Determine which role is appropriate for this rights profile.

   Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the other rights profiles are appropriate for users who are assigned to this role.

Decide which users should be assigned to the available roles.

According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. Keeping users away from tasks that they do not need to use reduces potential problems.

The Jail Chroot Project's purpose is to streamline the task of creating the chroot jail environment. It does so with utilities that "automagically configure & build all the required files, directories and libraries". It also makes adding new jailed accounts very easy. In this article, we'll take a look at the Jail Chroot Project utilities and show you how to install and use them to secure remote access accounts in a chroot-ed environment on your GNU/Linux system.

The basic idea

The Jail Chroot Project is the brain-child Juan M Casillas. On his web site, Juan explains how his utility works:

"Jail is a login tool. It works as a wrapper to the user shell, so when a user logs into the machine, Jail is launched, and the chrooted environment is activated. Then, Jail executes the real user shell, so he gets his session in the server.

The 'chrooted environment' is a subtree of the full tree in the filesystem, and the top of this subtree is viewed by the chrooted user as the root '/' entry of the tree. So Jail is useful for isolating users from the main filesystem's directory tree. As you can see in the diagram, the light-gray shaded boxes are the chrooted environment:"

Any user configured to be chroot-ed using Jail (such as user3 in the diagram) will be changed to his home directory (light-grey shaded box labeled user3) when that user logs into the machine. The root directory will appear to that user as the tree under the "chroot" directory. That is, user3 will only can see the files under the directory called 'chroot', thus locking that account in the "chroot jail", safely away from vital system files.

Installation

The installation of Jail Chroot is pretty standard *NIX fare. First, download the latest tarball (currently verion 1.9) at:

http://www.gsyc.inf.uc3m.es/~assman/jail/download/download.html

Once downloaded, simply unpack it with the command:

tar -zxvf jail_1.9.tar.gz

This will create a "jail_1-9_stable" directory where you unpack the file. Change directories to the one just created and you'll find a "src" directory. This is where you'll compile the utilities. Be sure to check the Makefile for your platform (Linux is set as the default). Simply issue a "make" and then "make install" as root to compile and install the utilities. Once you've gotten this far, you're ready to create the chroot-ed environment.

Creating the Jail

Once you've installed the Jail Chroot package, you're can build the chroot-ed jail environement. You'll need to decide where to build this environment, so take into consideration your partition sizes. For the purposes of this article, we'll create the chroot jail in the /home/jail dirctory. To set it up, run the following command as root:

/usr/local/bin/mkjailenv /home/jail

After executing the command, you should see text ouput similar to the following:

		Making chrooted environment into /home/jail
		        Doing preinstall()
		        Doing special_devices()
		        Doing gen_template_password()
		        Doing postinstall()
		Done.

Once complete, you've got a basic chroot environment installed in /home/jail. Now you'll need to add software for basic use in the jail.

Installing Software

The Jail Chroot utility adjailsw lets the system administrator choose between two methods of installing software for users in the jail. When your run the command without any arguments, addjailsw will add a default set of applications into the jail environment. To do this, run the following command as root:

/usr/local/bin/addjailsw /home/jail

This will install a group of basic commands for availablitilty in the chroot environment. These commands include some of the basics like ln, ls, mv, grep, cp, tail, touch and more. If you don't want to install the default set, you can use addjailsw with the -P option to specify each software package you want installed one by one in the chroot jail. For example, let's say you want to install the text editor joe. As root, just run the command

/usr/local/bin/addjailsw /home/jail -P joe

This will install joe for the chroot environment.

Adding inmates

Once you've added the software for your chroot environment, all that's left is to create user accounts. Prior to creating a user to the jail, you'll need to add him to your system in the normal fashion with adduser. You can use the adduser variables to create the appropriate paths in your main /etc/passwd file, or simply add the user and edit the /etc/passwd file manually. Any user placed in the jail should have their home directory listed as the chroot jail (/home/jail in our earlier example) and should specify the shell as /usr/local/bin/jail. The entry in the /etc/passwd file for a chroot-ed user should look something like this:

username:x:101:101:Jail User:/home/jail:/usr/local/bin/jail

Once you've specified the user to be jailed in your main /etc/passwd file, you can must then add him in chroot-ed environment. The Jail Chroot utility for doing this is called addjailuser and it has a very simple syntax. You must specify 4 variables when adding a user with addjailuser in the format:

addjailuser chrootdir userdir usershell username

The "chrootdir" variable is the path to the jail you've created. In our example, that would be /home/jail. (As you can see, this makes creating users in multiple chroot-ed environments very easy.) The "userdir" variable specifies the directory in the jail that will be the home directory for the user. To keep users consistent, we recommend creating a home directory for chroot-ed users just as you would for normal users. The only difference is that normal accounts will exist in the absolute path /home, and chroot-ed users will exist in the absolute path /home/jail/home, but will see essentially the same paths as normal users. The "usershell" variable points to the shell path inside the jail, so /bin/bash will be the norm, unless you install other shells in the environment. The "username" variable should be self-explanatory. Using these variables, you could add the username "fred" to our example jail in /home/jail with the command

addjailuser /home/jail /home/fred /bin/bash fred

This will create the necessary entries in the chroot-ed passwd file as well as create the directories for the user (/home/jail/home/fred) as well.

Simplicity and Security

Creating chroot jail environments used to be one of those dreaded tasks for system administrators. It was time consuming. It was tedious. And if you did something wrong, it was back to square one. The Jail Chroot Project streamlines these tasks and provides very easy to use tools for getting the job done. If you want to secure your remote access accounts with a chroot-ed environment on GNU/Linux (or any *NIX system for that matter), you need to get a copy of Jail Chroot Project tarball and get cracking. You'll be glad you did.

Chroot Jail Project Home Page

Slashdot Chroot Jails Made Easy

SecurityFocus/Configuring IPsec-IKE on Solaris Ido Dubrawsky, securityFocus

• Part One

• Part Two

• Part Three

RATS 2.0 released

RATS, the Rough Auditing Tool for Security, is a security auditing utility for C, C++, Python, Perl and PHP code. RATS scans source code, finding potentially dangerous function calls. The goal of this project is not to definitively find bugs. The current goal is to provide a reasonable starting point for performing manual security audits. RATS is released under version 2 of the GNU Public License (GPL).

Sudo Aliases and Exclusions

In his previous article, OnLamp's Michael Lucas looked at the basic sudo(8) setup. The hardest part of using sudo is configuring its permissions file, sudoers. As you can imagine, once you have several different machines with multiple administrators all with different levels of privilege, sudoers quickly gets very complicated. Aliases can simplify sudo maintenance and greatly clean up your sudo configuration.

Linux Journal On-Line

Stealthful Logging

Now it's time to combine the previous two techniques in a third one: stealth logging. Normally, a central log server runs syslog or syslog-ng. And indeed, it's possible to capture log packets via a non-IP-addressed interface with Snort and pass them to syslog or syslog-ng. However, it's a lot simpler to let Snort write the packets to a log file itself. The method I'm about to describe uses Snort, tail and awk instead of a traditional logger (on the central logserver, that is; on hosts that send logs you'll still need to configure syslog or syslog-ng as described below).

Suppose you have a LAN segment with several servers whose log messages you'd like sent to a single log server. Suppose further that you're far less concerned with the confidentiality of these log messages than with their integrity. You don't care if anybody eavesdrops the messages, but you don't want the messages tampered with once they've been received by the central log server. Your log server, therefore, is connected to the LAN via a non-IP-addressed interface and will sniff log packets sent to a bogus IP address on the LAN.

Configuring Your Hosts to Send Logs to the Stealth Logger

On each server from which you wish to send logs, you'll need to do two things. The first step is to configure each sender's system logger to send its messages to the bogus IP. By ``bogus'', I only mean that no host actually has that IP address; it must be valid for the LAN in question. Suppose our example LAN's network address is 192.168.1.0/24 and our bogus logger-host address is 192.168.1.111. Servers on the LAN that use standard syslog will each need a line like this in /etc/syslog.conf:

*.info @192.168.1.111

On servers that use syslog-ng, you'll need several lines in /etc/syslog-ng/syslog-ng.conf, like these:

destination d_loghost { udp(ip(192.168.1.111)
port(514)); };
filter f_info { level(info); };
log { filter(f_info); destination(d_loghost); };

In either case you may wish to specify different criteria from simply saying ``all messages whose severity is 'info' or higher'', as shown in the above two examples.

Besides the appropriate lines in its logger's configuration file, each log sender will also need a static ARP entry for the bogus IP address. If your LAN consists of a hub or a series of ``cascaded'' hubs, this ARP address also can be bogus. If your LAN is switched, you'll instead need to specify the real MAC address (hardware address) of the log server. The command to add a static ARP entry on our example log-sending servers is:

arp -s 192.168.1.111 00:04:C2:56:54:58

where 192.168.1.111 is our bogus log-host IP, and 00:04:C2:56:54:58 is either a bogus MAC address or the real MAC address of our stealth logger's non-IP-addressed interface.

Now each server on our protected LAN is configured to send its logs to 192.168.1.111, and in the case of a switched LAN, they'll be sent to the stealth logger's switch port. Now all we need to do is configure the stealth logger itself

"Sree" <[email protected]> writes:

>Dear Friends,
>how to provide su access to oracle user and disable direct logging throught
>ssh or telnet. only for user oracle.On Sun systems.

On Solaris systems with RBAC (s8+, I think) you can make the oracle
user into a "role"; that disables direct login access to the account
and also allows you to specify which users can su to it.


see user_attr(4) and rbac(5).

Casper

I've been looking at PAM, and it's a handful, IMHO.

Here's what I'm after; the question is, is there something
I can cannibalize to do this?

When a user logs in, I want to prompt them for the group
they intend to use.  I can do all the logic of checking
to see they're in the group and so forth, what I can't figure
out is how to go about giving the prompt and getting the
response.

Do I want to add to the stack in pam.conf?  That is, do I
want to simply add a line in a configuration file and
(I assume) supply the module to process that line?
That seems like the thing I'd most like to do.  I want
to be able to run this on Solaris if necessary.  If I
can write a module to process a line in pam.conf, then
it's trivial to add in the module and edit pam.conf, and
viola, I've got my extra requirement on any and all
machines I want.

I tried looking in several modules which I thought
would do something similar, but i just don't see
where the prompt is being sent, or the reply gotten.
Can you tell me where to look in an existing module
so I can see how it's done?

Or maybe I have the wrong idea altogether about PAM?

j.
-- 
Jay Scott		512-835-3553		[email protected]
Head of Sun Support, Sr. Operating Systems Specialist
Applied Research Labs, Computer Science Div.                   S224
University of Texas at Austin

Post a follow-up to this message

In article <[email protected]>,
Jay G. Scott <[email protected]> wrote:

[snip]

>
>When a user logs in, I want to prompt them for the group
>they intend to use.  I can do all the logic of checking
>to see they're in the group and so forth, what I can't figure
>out is how to go about giving the prompt and getting the
>response.

[snip]

a tip from Bruce Hudson (thx) got me started.


what i found out was that, while you can call setgid() from
lots of places, the only one which i found would remember
that setgid() had been called was in the pam_sm_setcred()
routine.  however, i couldn't get pam_setcred() to do the
prompting like i thought it should.  pam_sm_authenticate()
would prompt, but setgid() wouldn't be remembered.

i also didn't know that the way to get values passed from
one routine to another was via pam_set_data(),
pam_get_data().  now it's easy:  authenticate prompts
and calls pam_set_data(), setcred calls pam_get_data()
and calls setgid().

that, plus some relatively easy mods to pam.conf, and
i'm almost in business.

i notice that CDE's window for getting the group (my
addition, that is) contains the username, as though
that was the default group.  seems like that ought
to be a matter of zeroing the response msg before
calling the prompt, but to me, it looks like it is
zeroed.  perhaps i can simply supply new structs or
something.....

j.

-- 
Jay Scott		512-835-3553		[email protected]
Head of Sun Support, Sr. Operating Systems Specialist
Applied Research Labs, Computer Science Div.                   S224
University of Texas at Austin

http://travcom.tripod.com/ Free tools; two of note

• ps unhide - from [email protected] - shows process IDs in use, even if ps is trojaned
• viz.pl - show if someone has run zap or zap2 (log file erasers) on your system.

RC22534 "Thirty Years Later: Lessons from the Multics Security Evaluation." This is a fresh look, after 30 years, by the guys who did the seminal security analysis on Multics.

GeodSoft How-To Hardening Systems, Users, Groups and Security -- George Shaffer page. He understand this littly understood area of Unix security better than most.

PatchPro Select here to download Patch Manager Base 1.0.

This application allows you to analyze your system, download required patches and install them. It also resolves patch dependencies when you install individual patches. Patch Manager Base 1.0 uses PatchPro to analyze, download and install patches. It has the same security features as PatchPro for Solaris 9.

Alexander Geschonneck's security page This is a purely link page that contains some interesting links.

Solaris 9 Operating Environment Data Sheet -- Security in the Solaris 9 Operating Environment. It took Sun only ten years to integrate TCP-wrappers into the system ;-) Still if they managed to postponed this till 2002 it's unclear why not xinetd :-) Among other things:

Solaris Secure Shell -- Now integrated into the Solaris 9 Operating Environment, Solaris Secure Shell enables secure and easy-to-use network administration. Based on the established OpenSSH...

System Minimization -- The new system packaging architecture of the Solaris 9 Operating Environment enables organizations to custom build a Solaris 9 system based on a higher granularity of available install packages. In short, fewer unnecessary packages installed on a system means fewer opportunities for system attack.

For example, Telnet is a standalone package as opposed to being a part of the core package. This allows for a system configuration where only service-specific features and systems applications are installed, and mitigates the risk of introducing a potential security hole.

Configuring TCP-IP

In case the install program doesn''t let you configure the network properly, you can do it by hand afterwards.

• /etc/nodename - put the nodename in there (sunbox)
• /etc/hostname.dnet0 - put the IP/hostname for that interface there (sunbox)
• /etc/defaultrouter - put the default gateway IP or name (gateway)
• /etc/inet/hosts - first set it writeable by root (chmod u+w /etc/inet/hosts), and then add the hostnames for your local machine and the gateway at a minimum
• /etc/inet/netmasks - put the local network(s) and netmasks in there

Configuring DNS

• copy /etc/nsswitch.dns over /etc/nsswitch.conf
• /etc/defaultdomain - put the default domainname (example.org)
• edit /etc/resolv.conf so you have:

nameserver 1.2.3.4
domain example.org
search example.org

Running BIND v8 chrooted on Solaris 5-6-7

FOCUS on Sun Solaris Default Processes and init.d Pt. I

This article has been written to provide insight into a stock installation of Solaris 8, and the services started by default. Solaris 8 by default runs many services. This example was provided using Solaris 8, which is the latest version available, and a Sparcstation 20. Most of this document will apply to releases of Solaris prior to 8, and to both the Sparc and Intel architectures. For documentation purposes, a full OEM install was done. Many topics discussed will be familiar to seasoned administrators. However, this document will benefit all parties involved in the administration and security aspects of Solaris.

FOCUS on Sun Solaris and inetd.conf Part 1

This collection of material has been written to further clarify one of the more mystical configuration files on today's Solaris Operating System. For this example, we make use of the latest distribution of Solaris (at this time, 7). The topics covered are quite familiar to most seasoned administrators, although this publication has been written with administrators from beginning to advanced skill levels in mind.

***+ SAGE ;login - Auditing - The Ugly Duckling of Computers -- old but useful paper [ Jul 10, 2000]

Setting Up Auditing: The Specifics for Solaris 2.X

The auditing package that comes with Solaris is part of the BSM (Basic Security Module) package. The audit daemon auditd is the process that performs the auditing on Solaris systems. It is started by default if the /etc/security/audit_startup file exists. The actions that can be audited are defined in the /etc/security/audit_event file. This file can be customized, but it is very in-depth and beyond the scope of this article (the answerbook has a very good description of the whole process and files involved).

Audit flags indicate which classes of events to audit. Systemwide defaults are listed in /etc/security/audit_control. This file is very important and is the basis for the rest of the discussion. This file is similar to the "User Manager->Polices->Audit" setup in NT; it controls will be audited on the system and what will not. Set up improperly, and you will either have too much information or too little. A man on audit_classes(4) will give you a large amount of information. In standing with my initial recommendations, here is an audit_control file to start with:

dir:/etc/security/audit
flags:lo,ad,-fm,-fc,-nt
naflags:lo,ad
minfree:10

Let's see what this means. The first line defines the directory for the audit files to be placed. This location must have adequate space; if it fills up it will lock you out.[1] You can have more than one dirflag in the file, and they will be used in the order specified. The second line is for events attributable to a user, and tells us the following: (see the audit_event file for list of actions that fall into a class):

lo ­ all login and logout events
ad ­ all administrative actions
-fm ­ all failed change of object attributes (chmod, flock, etc.)
-fc ­ all failed creation of objects
-nt ­ all failed Network events (This may be noisy)

The third line is for events that are not attributable to a specific user. The fourth line tells us the minimum free in the dir files before we get a warning message from the audit system. The audit -s command will cause the auditd to reread this file after editing.

The other file of interest is the /etc/security/audit_user. This file allows more specific auditing of individual users. If specified, the flags in this file are combined with the global flags in audit_control to provide a more granular auditing ability.

Keeping Solaris Audit Files Manageable

To keep audit file manageable, a cron job can be set up to periodically rotate the audit files. The audit -n command will checkpoint the logs. This process closes the current audit log and opens another. Then you can process the just closed audit file. Figure 1 is a rudimentary script that will process the just closed audit log. Figure 2 is a script to store and rotate audit logs created during the auditreduce portion, a simple modification of the newsyslog script.

Audit maintenance on Solaris has a steep learning curve, but it flattens out pretty quickly. The best documentation is in the answerbook. It is specific and very descriptive. I recommend that anyone not strongly familiar with Solaris auditing read it before you implement the system.

Conclusion

Now that my primary job is helping those unfortunate individuals or sites with security incidents, I see the errors in not taking the time in 1991 to "finish the job." In an incident, if you don't have good logs (i.e., auditing), you'd better have good luck. The chances of figuring out what happened without good auditing are few and far between. If you take one thing from this article, make it this: Take the time, learn your systems, and set up auditing that is adequateand appropriate for your systems.

In the next issue, I will discuss central management of UNIX and NT audit files.

Sun BluePrints OnLine - Articles January 2000 SolarisTM Operating Environment Security -- PDF document. By Alex Noordergraaf and Keith Watson [Jan 2000].

The Solaris Operating Environment is a flexible, general purpose operating system. Due to its general nature, changes must be made to secure the system against unauthorized access and modification. This article discusses the Solaris Operating Environment subsystems and the security issues surrounding those subsystems. Recommendations are made on the manner in which those subsystems should be secured.

As with any security decisions, a balance must exist between system manageability and security. Some changes in this article will not be applicable to all environments. The removal of some of the Solaris Operating Environment services mentioned in this article may negatively impact the ability to effectively maintain a system. You must know your system and security requirements before starting.

This article splits the discussion of the Solaris Operating Environment system security into two parts. The first section deals with file system and local security. The second half of this article deals with the security of network services.

The information in this article applies to the Solaris 2.5.1, 2.6, and 7 Operating Environment. Some system changes described in this article have been integrated into Solaris 8 Operating Environment. Where appropriate, these new changes are mentioned. Older versions of the Solaris Operating Environment may be configured in similar ways. Some investigation is necessary before making the changes suggested in this article to these older versions.

***** SolarisTM Operating Environment Minimization for Security- A Simple, Reproducible and Secure Application Installation Methodology

***** Solaris^TM Operating Environment Network Settings for Security
-by Keith Watson and Alex Noordergraaf
Discuss the many low-level network options available within Solaris and their impact on security.

Etc

• Network Magazine Back Issues January 1999 Managing Unix Security
• Solaris - tuning your TCP-IP stack [Jan 15, 2000]
• Medstat Operations Manual -- online book for Solaris [Jan 12, 2000]
  • Contents

• Solaris Security Issues -- pretty recent slides with comments (from University of Pennsylvania Friday, October 22, 1999 UNIX Security Workshop)[Jan 12, 2000]

• POLYCENTER Security Compliance Manager for Solaris 2, Version 2.5 -- something old.[Jan 10, 2000]

• Sun Security Information[Jan 10, 2000]

• Basic Solaris Security Setup from SDSU_Security_Index[Jan 10, 2000]

• Univ of Oregon Solaris Security -- good; contains unique info on some steps (adding ASET, etc.)[Jan 10, 2000]

• docs.sun.com System Administration Guide Executable Stacks and Security[Dec 20, 1999]

• Sun Security Bulletin Archive

• Hardening the Linux Kernel (series 2.0.x) ---[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 06 of 20

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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

Most popular humor pages:

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

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

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

Last modified: March 12, 2019