Thoughts about Security

1
Thoughts about Security

• The price of liberty is eternal vigilance John
  Philpot Curran, c.1780
• Quis custodiet custodies ipsos?
• Perhaps the biggest single threat to security is
  believing that a system is secure. No system is.
  All systems have vulnerabilities. Better have
  some idea of what they are.
• All complex systems require someone else to be
  trusted. You cant do it all yourself. Better
  know whom or what you are trusting.
• Information about security problems is constantly
  updated. Better keep in touch.
• Security costs, not just directly in money, but
  also in inconvenience and bother. At some point
  the cost exceeds the risk - better live with the
  risk.
• Security products can themselves be insecure.
  Safest if open to inspection by a wide community.
  Better know how the checks are checked.
• Organisations need a security policy, which
  identifies assets that need to be secured, major
  points of vulnerabilities, and appropriate
  actions.
• Actions involve people management, hardware
  restrictions, software restrictions, including
  ensuring the OS is as secure as possible. No
  point having secure passwords if people write
  them on the wall, or if intruders can take the
  backup disks.

2
OS and Security(1)

• OS needs to ensure that only those authorised can
  access resources, and that the system resists
  attempts to stop it working or cause a crash.
• OS needs to protect itself and the resources it
  controls. Needs to ensure users are who they say
  they are authentication.
• Modern OS work at two levels (at least), the
  kernel level and the user level. The computer
  hardware on which the OS runs most support two
  modes, supervisor (kernel) mode and user mode. It
  must be possible to ensure that only trusted code
  can run in kernel mode, and that resources can be
  tagged as only accessible or changeable in kernel
  mode.
• The OS uses kernel mode to set up process control
  blocks, page tables, other system level stuff,
  and to do process scheduling and switching. The
  page tables etc. constrain what can be accessed
  by user mode code, protecting the the other users
  and the system itself.
• Protection needs to cater for a user running a
  trusted program, which accesses a data file
  that the user cant access directly e.g. a user
  may need to change a password, but should not be
  able to access the password file directly - cf
  Unix access permissions SUID bit.
• Protection needs to allow users work
  co-operatively. Most systems allow users to form
  groups or domains sharing access to some
  resources. Need to restrict individual group
  members. cf. Unix Sticky bit

3
OS and Security(2)

• Authentication is a big issue. How to ensure the
  user is who they say they are?
• Depending on the risks, may use biometrics such
  as fingerprints, iris scan, voice,
  challenge-response, or just password. Most
  systems depend on passwords.
• Usually the OS stores not the password itself,
  but rather a hash calculated from the password,
  such that the password cannot be calculated from
  the hash. When a password is entered, the
  corresponding hash is calculated, and checked
  against the stored hash.
• This system ensures that knowing the password
  file does not allow the passwords be calculated.
  However, it is vulnerable to a dictionary attack
  where each of the words in a large dictionary is
  hashed and the result checked in the password
  file if the same hash is found the password is
  now known. Its important to use passwords that
  are not words. Also the password file should only
  be accessible by a trusted program.
• Other OS constraints on passwords
  include limit the number of retries long
  delay after say three tries specify minimum
  length to protect against brute force limit
  lifetime protect against them getting
  known limit reuse cant reuse if e.g. one of
  last five in case get known special login
  bypass Trojan horses

4
OS and Security(3)

• Other protections include monitoring the system
  for files with unusual access privileges, or for
  unusual behaviour, such as many failed attempts
  to login from a remote site.
• Some systems keep a log of all login attempts,
  both successful and failed of course, if the
  system is compromised, this log itself can be
  tampered with.
• All complex OS have bugs which cause security
  weaknesses. These can be quite obscure e.g.
  inadequate protection against buffer or stack
  overflow. WWW sites providing information on them
  should be consulted regularly.
• Apart from OS weaknesses, need to protect against
  viruses, worms, the outside world generally, and
  similar delights, but thats another story.
• cf. http//www.alw.nih.gov/Security/security.html
• http//nsi.org/compsec.html