From: Pugh, David
Sent: Thursday, May 15, 2003 1:19 PM
To: lsa-dev-osx@umich.edu
Subject: [Mac OS X - security] May13 meeting minutes

Mac OS X Security
May 13, 2003
Meeting Minutes

Attending:
	Dave Pugh (dpugh)
	Mark Montague (markmont)
	Suleman Diwan (suledwan)
	Chris Brenner (cbrenner)
	Jim Jeffries (jwj)
	Jeff Kopmanis (kopmanis)
	Lewis Donofrio (donofrio)

Future meetings will be every Tuesday, 1:30-3:00 at the house.

Everyone should subscribe to the "security-announce" list at lists.apple.com

PHYSICAL SECURITY
-----------------
cable locks?  Nothing to mandate, good to recommend
Discussed writing UM asset tag number to NVRAM
  Good: track movement of physical hardware,
        know which machine to put fallen / mixed up tags on
        could be used for identifying a machine without turning it on
        may be useful for theft investigation
        can be used to identify hardware swapping (intentional removal
           or swapping of asset tag to hardware)
   Bad: requires human intervention to enter number (although only once)
        anyone with root/admin can change/erase NVRAM variables

PREFERENCES
-----------
Screen effects:
  - enable by default
  - use LS&A screen saver by default, but departments (Physics) need a way
    to change this on all machines (configurable load option)
  - enable hot corner (upper right to activate)
  - how is a password checked for unlocking?  Does it use the "Apple
    Security Manager Framework", and if so, how would that tie into Kerberos?
    Jim will talk to Phil, Jeff will talk to John
  - Security issue: screen effect can't be counted on to protect a 
    machine completely - can reboot into single user mode or off CD

Sharing:
  - Services
    - Enable "Remote Login" for SSH/SCP access
    - Do not activate any other services
    - Can/should we hide other services (file sharing, etc) so they can't be activated?  If we hide them, must be able to unhide them at a department level
    - on some machines (like psych) if a machine is compromised
      (or poorly shared), it may do more than affect the machine owner.
      Mark brought up the HIPAA act regarding patient privacy.
  - Firewall
    - Enable firewall - block all inbound ports by default
    - ports to enabled:
      - SSH (will be enabled when service is activated)
      - AFS (7001?)
      - NetOctopus (what ports?)

LOGIN/LOGOUT
------------
What to authenticate against?
  - can we get Kerberos tickets for both lsa.umich.edu and umich.edu?
  - lsa.umich.edu Kerberos realm WILL merge with umich.edu, but we don't
    know when.  Following the merge, you can use umich.edu tickets to
    obtain a LSA AFS token.

ACCOUNTS
--------
Be sure to understand the destinction between root and admin:
  - MacOS X comes with root "disabled".  Think of it as there, but
    with an unknown password.  An admin can become root simply
    by doing "sudo /your/favorite/shell"
  - An "admin" is just a regular user with the ability to sudo.
    This is no safer than giving the person the root password, but
    helps by requiring a password to be entered before running
    any privileged commands.
Need a local account for machine owner.  This will be an admin account
Need x number of accounts for remote administration, that must have
  a centrally changable password.  Departments will have the option
  to have a shared admin account, or use individual DSA accounts.
Do we need a genuine root account?
Netoctopus is a client, and doesn't require a local account
Need to explicitly set UIDs to match U-M UIDs
Short-names must match uniqnames

THINGS TO PONDER
----------------
Would it be useful (worth the trouble) to write UM asset tag number to NVRAM?
Hide other services (file sharing, FTP server, etc) so they CAN'T be enabled? 
Any other firewall settings need to be configured to block things by subnet
   for example?
Any reason to have a genuine 'root' account, or are "admin" accounts enough?
If we do have a 'root' account, disable direct SSH access as root?
Read up on "iHook"
What can (SPG) and should we do with respect to monitoring?
Concerned about the "single user mode root vulnerability"?
  - options include openfirmware password, inserting a custom
    script into the rc startup file(s) to ask for a password,
    and possibly changing 'secure' to 'insecure' in /etc/ttys
What needs to be accomplished upon logout?  (kdestroy, etc)