CSUS Intro to Security for CPSC Students

Author: Chad Clark ( ccclark @ ucalgary . ca )

This means send me corrections / updates / comments / etc.


TOC:

  1. Changes

  2. Preface

  3. Notes on UNIX

  4. Why Worry?

  5. Passwords

  6. File Permisions and UMASK

  7. Watch Your $PATH

  8. History

  9. PGP and GPG

  10. Thanks




  1. Changes

    I've made few changes to this document. The "current" version (ie the last time it changed) now lives on http://www.superfrink.net/ as I no longer maintain the CSUS web site. Changes do include some bug fixes and reworking in the umask section. I'm also thinking of removing the PGP section as the version on the CPSC machines was changed and I'm not sure how many people actually use PGP. Finally I'm dating this file as unchanged since 07 Nov 2002.


  2. Preface

    This is ment to be an aid to students new to Computer Science at the University of Calgary. We explain the basic steps you can take to protect your files and your reputation with respect to the UNIX like systems we use here (Solaris, GNU/Linux and, maybe even AIX).

    Most certainly this is not the end of system security. Nobody can protect you from every possible security problem because new issues are continually being found (and we can't predict the future well enough yet to know where problems will be found tomorrow). The computer world, especially 'the' internet, is growing quickly. So quickly that much of the software in use has not been tested for an extended period of time yet.

    This is not ment to sound threatening or scary, it is just the truth. We live in a world where we have to look after ourselves a bit. Hopefully this document will help you out in the wonderful world of Computer Science.

    My apologies for the misuse of the name 'Eve'. Typically that name has been used strictly with respect to an evil person in discussions of cryptography. Here it used to refer to whoever wants access to your account or files.


  3. Notes on UNIX

    The history books claim that UNIX was designed to be a system for a community of users. Ease of use (as far as programmers feel ease of use needs to be) and implementation were primary concerns. Security came second after it was discovered that we needed a bare set of security measures. Advances like Access Control Lists are coming but the weakest link is still the human factor.


  4. Why Worry?

    What is all of the fuss about? After all it's not like we keep bank records on our school accounts. Hopefully you don't keep your personal information like bank records on public systems. The computers at school are available to hundreds of students and staff. Any one of them could be interested in your account.

    Suppose Eve is having trouble with an assignment and you're done. If she were desperate enough she may be tempted to steal your work. Maybe Eve wants to commit some act and doesn't want it traced back to her. She could hide behind your account and you could be blamed.

    Read the agreement you signed to get your account. You are responsible for EVERYTHING that happens through that account. If you leave your terminal unattended and your account gets used for something who do think is going to be questioned? Even if you don't care about your files being erased you should still protect your account.


  5. Passwords

    Passwords are your first line of defence. In one case out of 1000 passwords 996 were 'cracked' (see: Toxen). So 0.4% of the passwords were 'good' passwords. People like to have easy to remember passwords but easy to remember often means easy to guess. This is why when you change your password you are forced to chose wonky looking passwords.

    The first thing to do when you get your account is to change the default password. To do this type the command passwd. You will be prompted for your current password. This is to confirm that you really are the owner of the account. Next you will be asked twice for the new password you would like. This is because you may make a typing mistake as you can't see the characters while you enter them. The keystrokes are not shown on the screen because Eve may be looking over your shoulder as you type your new password.

    A sample password change would look like this:

    darkstar:~$ passwd
    Changing password for frink
    Old password:
    Enter the new password (minimum of 5, maximum of 8 characters)
    Please use a combination of upper and lower case letters and numbers.
    New password:
    Bad password: too simple.  Try again.
    New password:
    Re-enter new password:
    Password changed.
    darkstar:~:$ 
          
    We can see that the first password I tried was too simple to guess so it made me pick a harder one. This is to prevent 'dictionary attacks' where every word in the dictionary is tried as a password. This also make 'brute forcing' take longer. Brute forcing the password is done by trying combinations 'aaaa', 'aaab', 'aaac' and so on. But what makes a good password? A password should:

    Well that seems to leave very few choices. One method that produces cryptic looking passwords is to take a sentence and use the first letter from each word mixed with some extra symbols. For example 'One dollar is less than four bucks.' might come out as ' 1$ilt4B '. Using this method we only have to remember a phrase (and how to type it) which is easier than remembering an arbitrary string.

    When creating passwords we try to do two things. First it has to be hard to guess, often the attacker knows us. Second we are trying to make it computationally difficult to work out. An attacker may use a program that tries to login using your login ID and every possible password.

    Change your Computer Science password as soon as you get your account. The department will try to crack your password by trying many possibilities. If they succeed your account WILL be suspended. This is to protect everyone on the system. If they can crack your password then Eve probably could too.


  6. File Permisions and UMASK

    First of all this section deals with file permissions which I assume you've seen before. We will only be looking at changing the default file permissions. If you find yourself getting lost I recomend either this excellent explaination written by Daryl "Big-D" Suttie or part of another document written by Mark Leonard and myself.

    This is one of the easy things to fix. When you create a new file or directory it is given a set of permissions. The permissions depend on a thing known as umask. The file is created with a basic set of permissions. For files this is 666 and for directories it is 777. Next the umask is applied. The umask "masks" out any permission bits that are set in the umask. Whatever permission bits are left become the final permissions the file or directory is created with.

    Creating a new file when the umask is set to 022 looks like this:

        1) Base permissions   --->  666   ( 110 110 110  or  rw- rw- rw- )
        2) umask              --->  022   ( 000 010 010  or  --- -w- -w- )
        -------------------------------------------------------------------
        3) Final permissions  --->  644   ( 110 100 100  or  rw- r-- r-- )
        

    Creating a new directory when the umask is set to 022 looks like this :

        1) Base permissions   --->  777   ( 111 111 111  or  rwx rwx rwx )
        2) umask              --->  022   ( 000 010 010  or  --- -w- -w- )
        -------------------------------------------------------------------
        3) Final permissions  --->  755   ( 111 101 101  or  rwx r-x r-x )
        

    Lets look at a real example.
        sh-2.04$ umask
        022
        
    When we type the umask command our shell tells us that the umask is currently set to 022. So if we create a file the group write and other write bits should be masked out (and all execute bits because this is a file not a directory).
        sh-2.04$ touch asdf
        sh-2.04$ ls -l asdf
        -rw-r--r--   1 frink  users             0 Aug  1 23:14 asdf
        
    This certainly looks like the case. Notice that the execute bits are not set for anyone. Now lets change our umask so that only the bits for ourself will be allowed through.
        sh-2.04$ umask 077
        sh-2.04$ touch qwerty
        sh-2.04$ ls -l qwerty 
        -rw-------   1 frink  users             0 Aug  1 23:15 qwerty
        sh-2.04$
        
    So we want our umask to be 077 all of the time to keep our files from being set to 644 by default. The easy way to do this is put the line
    umask 077
    in one of your startup script files. If you are using BASH then ~/.bash_profile works. For CSH or TCSH you can use ~/.cshrc.


    Here is one more example:

    bash-2.05$ ls -la
    total 4
    drwxr-xr-x  2 frink  users  512 Mar  1 23:01 .
    drwxr-xr-x  3 frink  users  512 Mar  1 23:01 ..
    bash-2.05$ umask
    022
    bash-2.05$ touch afile
    bash-2.05$ mkdir adir
    bash-2.05$ ls -la
    total 6
    drwxr-xr-x  3 frink  users  512 Mar  1 23:02 .
    drwxr-xr-x  3 frink  users  512 Mar  1 23:01 ..
    drwxr-xr-x  2 frink  users  512 Mar  1 23:02 adir
    -rw-r--r--  1 frink  users    0 Mar  1 23:02 afile
    bash-2.05$ umask 077
    bash-2.05$ touch file2
    bash-2.05$ mkdir dir2
    bash-2.05$ cat > nonemptyfile
    this file has stuff in it.
    bash-2.05$ ls -la
    total 8
    drwxr-xr-x  4 frink  users  512 Mar  1 23:02 .
    drwxr-xr-x  3 frink  users  512 Mar  1 23:01 ..
    drwxr-xr-x  2 frink  users  512 Mar  1 23:02 adir
    -rw-r--r--  1 frink  users    0 Mar  1 23:02 afile
    drwx------  2 frink  users  512 Mar  1 23:02 dir2
    -rw-------  1 frink  users    0 Mar  1 23:02 file2
    -rw-------  1 frink  users   27 Mar  1 23:02 nonemptyfile
    bash-2.05$
        

  7. Watch Your $PATH

    When you type a command at the shell prompt the shell has to find the actual command to run. So when you type 'ls' the shell has to find '/bin/ls'. The shell could check every possible file on the system but it would take to long. To keep the search short the shell a environment variable called $PATH. The $PATH variable is just a list of paths to look in when looking for command programs. To see you $PATH variable just type echo $PATH. It should look somewhat like this:
          darkstar:~$ echo $PATH
          /usr/local/bin:/bin:/usr/bin:/usr/games
          darkstar:~$ 
          
    The semicolons separate the actual paths to be checked. Often this list will include the current working directory, denoted as a dot much like:
          .:/usr/local/bin:/bin:/usr/bin:/usr/games
          
    The 'trick' goes as follows. Eve puts a nasty program named 'ls' into her home directory. Then she tells you she is having some problems with her account and asks you to have a look. Being the nice person you are you type the following:
          cd ~eve
          ls
          
    At this point the damage is done. Whatever her 'ls' program did has been done and it was done as your user ID! It could have been something like:
          #!/bin/sh
          cp ~/cpsc231/as1.cc /tmp
          chmod 666 /tmp/as1.cc
          ls
          /bin/rm -f ls
          
    This would copy your as1.cc file into the temp directory and give everyone permission to read it. Just to be sneaky it calls 'ls' too so you don't even notice anything wrong.   - try this with 'ls -l' and you will notice but the damage would be done and the evidence is gone.   :)

    The only reason her program would work is that the current working directory is the first thing in YOUR $PATH variable. This is why the dot should not appear in your path at all.


  8. History

    The UNIX shells have a nice time saving measure. They keep track of the past commands you have typed. To see what they are type history. A big list shows up with a number in front of each command. The easy way to redo a previous command, say item number 12, is to type !12. This is great but often your commands are stored in a file (usually it only gets written to disk when you log out). '~/.bash_history' for BASH users, '~/.history' for CSH or TCSH and, maybe '~/.sh_history' (for KSH). To keep other people from being able to read your history file you should make sure the permissions are set to 600. Here is how to do that:
          darkstar:~$ ls -l .bash_history 
          -rw-r--r--   1 frink    users        5633 Jul 28 20:44 .bash_history
          darkstar:~$ chmod 600 .bash_history 
          darkstar:~$ ls -l .bash_history 
          -rw-------   1 frink    users        5633 Jul 28 20:44 .bash_history
          darkstar:~$ exit
          
    The historical reason for protecting this file is to keep people from finding passwords that were used on a command line. You shouldn't have to enter passwords on a command line but it's still a good idea to keep people from reading what you have been doing.


  9. PGP and GPG

    PGP stands for Pretty Good Privacy. PGP is set of programs that let you share enciphered messages with others or keep your own data enciphered. On the CPSC machines type pgp and it will give you a list of commands to use instead of having multiple complicated command line options. PGP is available from MIT's site if you wish to use it at home. GPG is GNU's own encryption program that is starting to gain popularity. Info on it is available from GNU's site HERE.

    PGP works using a public-key system. It is called public key because we give out a key for the world to use. Anyone can find my public key and use it to encipher a message. Then the enciphered message gets sent to me (usually by email). Next I have to use my private-key and my secret 'pass phrase' to decipher the message. We call it a pass phrase and not a password because it can be many lines long. This make brute forcing much more difficult.

    Because PGP 5.0i is available on the CPSC Sparc servers it will be used to illustrate PGP in the following examples.

    To generate a new key pair you would type

    pgpk -g
    You will be asked to chose a key type. Pick RSA because more people will be able to use it. You need a more recent version to use DSS. Next pick the strength you want to use 1024 or 2048 should be fine. Next you have to enter a key ID. Use the format shown on the screen. (ie FirstName LastName < user@cpsc.ucalgary.ca > ) Next you are asked how many days you want this key to be valid (ie. how long you want to use it). Most people just enter 0 which means 'never expires'. This is fine to do. If you use news keys frequently then you should have better security but it is more work. Now the fun part, it wants a pass phrase. A single sentence is a good idea but don't use any line that has been published (ie 'Luke I am your father.' or 'To be or not to be.').

    The next step is to enter some random keystroke's. Here PGP is measuring the time in between each key to get random numbers for it's calculations. And the last step. PGP wants to know if you want to send your new key to a 'key server'. A key server keeps a list of many PGP keys so if you wanted to find Bob's key you would just ask the key server. Just leave this blank. That way if anyone wants you're key they have to get it directly from you.

    The next thing you want to do is extract your new public key so you can give it out. To do this type pgpk -x USERNAME > pub_key.asc where USERNAME is your ID part of your email address. We redirected the output to the pub_key.asc file. Now when you want to give someone your public key you just give them a copy of this file. You can email it or put it on your webpage. To see what it looks like type cat pub_key.asc. When people give you their public keys you have to add them to your public key-ring. We do this with the pgpk -a FILENAME where FILENAME is the name of the file with the key in it (for us this was pub_key.asc).

    When you want to encipher something with someones public key their public key must be on your public key-ring. The command is pgpe -a -r BOB -o OUTFILE INFILE. The -a means ASCII output so the output is safe to email. The -r BOB means BOB is the recipient (ie who we are enciphering this for). The -o OUTFILE means that we should use OUTFILE as the name of the enciphered message file. Lastly INFILE is the name of the file with the message we are enciphering. Now all we have to do is send the enciphered file (OUTFILE) off to BOB and BOB can use his private key and pass phrase to decipher it. Traditionally the OUTFILE has a .asc extension to denote an ASCII file.

    When Alice sends you an enciphered file you have to use the command pgpv INFILE to read it. INFILE is the name of the file with the enciphered message in it. You will be asked for you pass phrase. After entering the pass phrase PGP will probably create a new file without a .asc extension in your current directory. You can now read the new file with more or cat.


  10. Thanks

    Thanks to all of the following:
    For more interesting reading: