CSDL Linux Desktop Configuration

On Tuesday September 16 CSDL had a meeting regarding changes to the configuration management of lab Linux machines. Mostly it only focused on the process for deviating from a baseline configuration (which is yet to be determined). During the process of establishing a baseline configuration the following points need to be made:

Configurations for Linux

• Security considerations for Linux desktop are very different than Windows desktop. Why?
  • worms and virii do not exist on Linux
  • root/admin access is typically not required for performing day to day job duties so scope of damage is very limited. Root functions are limited to updating software and system maintenance.
  • code security is high priority in Linux. Security contributions are made from government, academic researchers and security minded companies. All Linux source code gets reviewed from a wide range of people.
  • Security considerations for Linux server are very different than a Linux desktop
  • servers are exposed to the outside world and have priviledged processes running that are attackable
  • Desktops do not

  We need to review what is our definition of "connected to the network"

  • If a machine accepts no in-bound connections there is no possible way to enter without physically being at the terminal
    • presents no security threat from outside sources
  • A machine with no in-bound connections is essentially a clean-room and is better than firewalled.
  • We require out-bound connections for getting documentation, software updates, etc.
  • Out bound connections pose essentially no threat.

  Should we consider some type of Linux distribution in which security is a priority?

  I looked over the NSA's Security Enhanced Linux (SELinux). Essentially it gives you a much more flexible policy based security which they call "mandatory access control". This allow different processes which normally have to be run as a privilidged user (i.e. root), to not be run as root and only be given the privilidges which they require. For example apache needs root access to bind to port 80 to accept in bound connections. With SELinux you could explicitly give apache that access, without requiring root and all of the extra security implications of having a root process running (potentially arbitrary) code. I think that we should definitely consider SELinux for our servers. However in userland, we generally don't need root access for day to day tasks (programming, running simulations, writing up documentation), so SELinux doesn't really buy us anything. In desktop configuration land, what we have now seems more than sufficiently secure.

  -----