Harish Narayanan wrote:

>Recently, the computer support people at the department have been
>drafting a security policy for what OSs they allow running on
>departmental computers, and long story short, they list the upstream
>vendor's product[1]---and not SL---as an allowed Linux based OS. I tried
>explaining to them the binary and source equivalence of SL and this
>product, but they are not familiar with GNU/Linux, and I haven't gotten
>very far.
>  
>
I've observed that, after a prolonged discussion with you, your adviser,
your department head, etc, a compromise can usually reached.  Typically,
the compromise looks like the following:

   1. They will create some sort of official or unofficial exclusion for
      "clueful people doing intelligent things to get work done".
   2. All security problems are on your head -- not theirs.  They'll
      reserve the option to cut off your network access, if there's a
      problem.
   3. Don't bother them, and they won't bother you.  If your machines
      behave themselves, they'll bet you do your thing.


In order to spur the discussion, I'd offer the following:

   1. Background: Describe why this setup matches your groups needs
      better than a typical setup.  Any IT people who are worth anything
      realize that their organization has computers to help people get
      work done.
   2. Firewall: Offer to firewall everything (put it behind a
      Linksys-style NAT box (with the latest firmware, of course!) or
      something and have people SSH'ing into the lab connect to a
      central box, and then SSH to where they need to go -- or do some
      fancy port redirection).  If you're not running NFS, then the
      iptables firewall with an exception for SSH is good.  Or both!  If
      you do both, and then administer the machines as if they're on the
      open Internet, you're in good shape.  Make sure to mention that
      you know the firewall doesn't make your machines secure -- these
      folks hear from a lot of people who think that they can remove
      their e-mail virus scanner and web-spyware-removal-tools when the
      machine is firewalled.  But, if they don't trust your software on
      the open Internet, it will make them feel a bit better -
      especially when when it's evident that you know how firewalls fit
      into the overall IT toolbox.
   3. Virus Scanner: You can install clamav from DAG's repository.  It
      doesn't scan in realtime, but when they ask if you have a virus
      scanner on every machine, you can say "yes!".  If you put a clamav
      command in the crontab ("@daily /usr/bin/freshclam ; nice -n 19
      clamscan --recursive --no-mail --infected  /"), the machine is
      being automatically scanned.
   4. Monitoring: make sure ~root/.forward on each and every machine
      goes to an e-mail address that you read.  That way, you get
      logwatch reports (continuous monitoring of logs), and also the
      reports from the virus scanner(configured in Step 3).  Also, if
      you have any RAID volumes, the system will e-mail you when there's
      an error.  Sifting through the e-mails every day is slightly
      annoying -- but hugely useful for sysadmin tasks, and it also
      shows that you are conscientious.
   5. Match their security policy for Windows or Linux machines as
      closely as reasonable.  Go down the list and discuss how you
      implemented each item -- or why that requirement doesn't make
      sense, given what you're doing.  What's important here is that
      you've considered and understand all of the issues.

These suggestions ought convince the central IT folks that you're
clueful, conscientious, and taking the administration of the machines
seriously.  In the end, this is all any IT organization really wants.

-Luke

-- 
Luke Scharf, Systems Administrator
Virginia Tech Aerospace and Ocean Engineering