General Issues Concerning Linux Workgroup Configurations

Table of Contents

Appendices


1. Introduction

You will have noticed that these and related web pages fall under a section called Workgroup Recipes. As with most recipes in the kitchen, there are usually many possible ways to make (more or less) the same same thing. This is equally true for various workgroup server configurations.

Please remember as you look at configuration recipes presented here that many other possible recipes exist. Many other styles and philosophies might be used when setting up systems. Most importantly, global policies are important when you chose an information technology method. I might present a configuration that is appropriate for a workgroup with trusting relationships; however this might not be at all appropriate if you have a workgroup setup consisting of mostly hostile clients.

Therefore always use your common sense and assess the relevancy and suitability of any configuration recipes presented here. In short, know yourself. Do not blindly implement solutions just because they work without seriously looking at the assumptions and technological limitations underlying any configuration.

2. Policy Considerations

2.1  Subnet-driven Configuration

Many recipes here assume a subnet approach to configuration and security:

2.2  Trust-driven Approach

Some configurations described here would be appropriate for workgroups where a trusting kind of relation is in place. What do I mean by that?

By way of contrast here are some examples of typical untrusted relationships:

3. Login Access Policies

What do I mean by login access policies? Basically what I wish to do is describe various remote and local access schemes that a system administrator could implement across a Linux workgroup. These kind of policies are implemented frequently, for example, in academic networks.

Here are some examples, starting from the worst, in terms of security.

  1. This sort of thing was once rather common in UNIX-based systems: Everyone uses telnet and/or rsh, and system policies allowed unrestricted ~/.rhosts access in the intranet, and perhaps even across the Internet. (ie. no password required). Similar principles may even be in place for root access..
  2. Only ssh access is allowed; however it is globally allowed between all machines in the intranet and perhaps even to the Internet. Root-access is also permitted. ~/.ssh/authorized_keys* files without passphrases are allowed which remove the need to provide a password.
  3. Only ssh access is allowed from within the intranet. Access from outside the intranet is generally blocked. However one or two machines may be configured to allow Intranet-access via ssh. These few machines are firewalled, heavily configured and monitored. Password-less access is not allowed, except for some kinds of controlled and monitored access (e.g. cvs via ssh tunnelling).

4. Super-user Access Policies

Now what about super-user access? Suppose we take the last login access policy above (point c), and propose a layered model of super-user access for a linux workgroup, built around a concept of Core Servers.

A few (perhaps 2 or 3) critcal machines, which we call Core Servers, provide important services to the workgroup. These servers are configured differently than other small, dedicated servers in the company; and certainly differently from desktops. Here are some notes about configuration policy options that could be built around Core Service.

Appendix A : List of Important Concepts

This is the list of noteworthy concepts mentioned in this document:

Appendix B : List of Files

This is the list of files referenced in this document:


Contact: http://penguin.triumf.ca/home/
Created: Sat Jan 3 12:16 MET 2004
Last Modified: Tue Jun 1 13:37 2004
Copyright © 2004, Denice Deatrich

Document generation: http://penguin.triumf.ca/xml/WebHowTo.html

Number of sections provided: 4