The problem of identity

• assure that people are who they say they are.
• assure that people have the rights accorded them.

Two parts to administering user rights

• authentication: who is the user?
• authorization: what should this user be able to do?
• typically handled separately.

Authentication:

• Determining who the user is.
• Typically: username and password.
• For one machine: /etc/passwd, /etc/shadow.
• For a network: some form of network database.
  • NIS: "yellow pages".
  • NIS+ : sun proprietary
  • LDAP: Lightweight Directory Access Protocol
  • Same function as files.
  • Identifying which is used: /etc/nsswitch.conf

Network databases

• Not all user data is contained in /etc/passwd, /etc/shadow, /etc/group.
• Information is also kept in network-wide databases.
• Three prevalent databases:
  • the Network Information Service (NIS) (A.K.A. the Yellow Pages)
  • Sun NIS+.
  • the Lightweight Directory Access Protocol.

NIS

• Widely available.
• Supported virtually on all UNIX platforms.
• Insecure and easy to crack.
• Defacto standard.
• Domain-specific: only certain kinds of information can be distributed.
• Easy to administrate.
• How to get info:

   ypcat passwd | more
   ypcat group | more
  

NIS+

• Sun proprietary.
• Only on Suns with "weak" ports to other platforms.
• Sun doesn't use it in-house!
• Quite secure.
• Generic: information can be of virtually any type.
• Very complex to administrate.
• Can have multiple information domains spanning large enterprises.
• Concept of administrative delegation: can allow people with limited rights to edit parts of each domain.
• Precursor of X.25 and the Lightweight Directory Access Protocol (LDAP).
• How to get info:

   niscat passwd.org_dir | more
   niscat group.org_dir | more
  

Lightweight Directory Access Protocol

• Actually a directory service: provides such things as name, address, phone number.
• Can also be adapted to authenticate users.
• Supports limited delegation (NIS+ is roughly the same as X.25, the "heavyweight directory access protocol"; LDAP is a subset)
• How to get info:

   sun{couch}52: ldapsearch -h ldap.eecs.tufts.edu -b ou=People,dc=eecs,dc=tufts,dc=edu uid=couch
   uid=couch,ou=People,dc=eecs,dc=tufts,dc=edu
   uid=couch
   cn=Alva L. Couch
   givenName=Alva L.
   sn=Couch
   mail=couch@eecs.tufts.edu
   objectClass=person
   objectClass=organizationalPerson
   objectClass=inetOrgPerson
   objectClass=posixAccount
   objectClass=top
   objectClass=kerberosSecurityObject
   objectClass=shadowAccount
   objectClass=account
   objectClass=hordePerson
   ...
  

• Note: in other services, information is filed by function. Here it is filed by person.

Typical Authentication Architecture

• vmlinux (the kernel) invokes init (process #1)
• init invokes getty on a terminal (via /etc/inittab) On linux hosts, the system console (what you login to under UML) is made possible to access via the line

   0:2345:respawn:/sbin/mingetty tty0
  

  in /etc/inittab.

  meaning:

  • in runlevels 2,3,4,5 (2345)
  • run /sbin/mingetty tty0
  • and restart it if it dies (respawn).
  • (the first 0 is the name of the service, some distributions put 'co' there)
• getty invokes /bin/login couch when couch attempts to login.
• /bin/login reads password.
• /bin/login uses system calls getpwnam to get and check password.
  • If correct password, exec's login shell.
  • If not, complains and dies (allowing init to spawn another getty).
• We're not done! The system call getpwnam uses /etc/nsswitch.conf to determine where to get its password information from (files, nis, nisplus, ldap)

What gets used: nsswitch.conf

• /etc/nsswitch.conf: tells what name services are being used.

   #
   # /etc/nsswitch.nisplus:
   #
   # An example file that could be copied over to /etc/nsswitch.conf; it
   # uses NIS+ (NIS Version 3) in conjunction with files.
   #
   # "hosts:" and "services:" in this file are used only if the
   # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.
   
   # the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
   passwd:     files nisplus
   group:      files nisplus
   
   # consult /etc "files" only if nisplus is down. 
   # hosts:      nisplus [NOTFOUND=return] files
   
   #Uncomment the following line, and comment out the above, to use both DNS
   #and NIS+.  You must also set up the /etc/resolv.conf file for DNS name
   #server lookup.  See resolv.conf(4).
   hosts:     nisplus dns [NOTFOUND=return] files
   
   services:   nisplus [NOTFOUND=return] files
   networks:   nisplus [NOTFOUND=return] files
   protocols:  nisplus [NOTFOUND=return] files
   rpc:        nisplus [NOTFOUND=return] files
   ethers:     nisplus [NOTFOUND=return] files
   netmasks:   nisplus [NOTFOUND=return] files        
   bootparams: nisplus [NOTFOUND=return] files
   
   publickey:  nisplus
   
   netgroup:   nisplus
   
   automount:  files nisplus
   aliases:    files nisplus
   sendmailvars:   files nisplus
  

Several identity problems:

• clear-text (or otherwise replayable) passwords must die.
• single-signon and weakest links.
• assigning root privileges.

Risk: password replay

• telnet sends passwords 'in the clear'.
• Many tools exist for catching and reassembling passwords from network packets.
• If you have any unsecured PC on your network (or any hacker has access to root on any UNIX box), you're vulnerable.
• Attacker can simply `discover', `replay', and gain access to the same privileges.

Risk: other replays

• Substitute `Credit card', `Expiration date', and `Name on card' for a much more damaging example.
• Email is not secure.
• In France, secure email isn't legal.

Weakest links

• Suppose you use the same account for ssh and ftp.
• This means you use the same password for both.
• ssh is encrypted, so protected from snooping attacks.
• ftp is not encrypted, so it can be snooped.
• The ftp account and password are the same as the ssh account and password.
• So if you use ftp, your ssh access can be compromised!
• Substitute imap, pop email access for ftp ... same problem.

Desperate acts

• stamp out telnet: avoid cleartext passwords.
• ssh, sftp: provide secure shell and file access.
• simap, spop: provide secure email access.

Why haven't these simply `been done'?

• This is not simply a change to servers
• All clients must also be modified.
• This takes money and time.

Limitations

• No sftp client for Mac's < OSX
• simap clients require proper installation (labor and technical assistance).
• no simap for cellphones and PDA's.
• Waiting for technology to catch up with need!

Looking deeper: cracking passwords

• Passwords are hashed internally.
• Normal hashing: crypt
  • Input: plaintext password
  • Output: hashed password: 13 characters.
  • 2-character "salt": first two characters are "noise" added to password.
  • passwords cannot be easily inferred from the encrypted strings in /etc/passwd, but
  • one can simply try every word in the dictionary.
  • crack: a program that tries every word in the dictionary as a potential password.
  • poor man's CRACK:

     const char *trials = { "foo", "bar", "baz", "bum" };
     const char *coded = "8f73nd8fhd8fj";
     main() {
       for (int i=0; i<4; i++) {
         char *namep = crypt(trials[i], coded);
         if (strcmp(namep, coded)==0) {
           printf("got it! password=%s\n", trials[i]);
           exit(0);
         }
     }
    

• try: all words, star trek characters, profanity, ss#'s, birthdates, all permutations of login name.

Real-life stories

• You have a finite amount of time to manage a system.
• Abusers have much more time to break into yours.
• Typical strategy:
  • steal all encrypted passwords.
  • subject each one to extensive cracking.
  • Any password that's too weak is discovered.
  • Broadcast discovered passwords to a wide audience (to cover up who cracked the passwords).
• In practice: one person cracked 1,000 accounts on emerald. Similar results for sun (back when one could read encrypted passwords).

MD5 encryption

• Process passwords via a cryptographically strong hash
  • Function M(x)
  • Given x, easy to get M(x).
  • Given M(x), difficult to get x.
  • For x and y, usually M(x)!=M(y).
• Reference standard Message Digest 5 (MD5).

Important note:

• MD5 makes encrypted strings longer.
• This increases the number of significant letters.
  • crypt: 8 characters are significant.
  • MD5: any number of characters can be used.
• Using MD5 does not affect one's ability to crack weak passwords.
• Same procedure applies: try every word in the dictionary.

Choosing a strong password:

• mix letters, numbers, symbols.
• mix cases.
• Choose a password not based upon a word, but instead upon a phrase.
• E.g.,

   I come to serve. Your service honors us!"
   ^ ^    ^  ^    ^ ^    ^       ^      ^ ^
   I c    2  5    . Y    s       h      u .
   => Ic25.Yshu!
  

• A particularly fun password: "2b|!2b" (to be or not to be) was the root password of the very first sun in EECS, in 1985.

Password caveats:

• users are idiots^H^H^H^H^H^Hclueless and will use obvious passwords. I've actually seen several systems where user 'root' has password 'root'!
• even if you don't use an obvious password, it can be easily guessed if it's in the dictionary or one of a list of commonly used passwords, once a hacker has the encrypted version of your passwords.
• If a hacker can get access to your passwd file, you are toast! Out of emerald's old password file, about 30% of users had dumb passwords. This was 8000 * .30 = 2400 users!

Ways of making passwords more secure:

• shadowing: hide password in local disk.
  • only public information is kept in /etc/passwd (must be readable by everyone)
  • actual passwords are kept in private file /etc/shadow (only root!)
• nis+ directory service: only root and other authorized users can get to the password entries. Other users are simply denied access.

Ways of making passwords less secure:

• nis: (yellow pages) passwords valid on a network are available from any nis client. I.e., you don't just win, you win big if you can manage, on any host, to execute, e.g.

   ypcat passwd | mail bozo@phreak.com
  

STUPID PASSWORD TRICKS:

• set the shell to a command you want to execute:

   halt:3nfu23i3o4829:0:0:Halt and Catch Fire:/:/sbin/halt
   reboot:3nfu23i3o4829:0:0:Reboot the System:/:/sbin/reboot
   sync::0:0:Synchronize Disks:/:/sbin/sync
   kill::0:0:Kill all emacs processes:/:/usr/local/bin/killallemacs
  

• use an alias for root intentionally to grant short-term access via another password:

   jack:28n3nfndis9df:0:0:Jacks' temporary root account:/:/bin/sh
  

• use an alias for root in order to use a better shell:)

   toot:8fjd9shfjdhsd:0:0:Root with ultra-winning t-shell:/:/bin/tcsh
  

• set the shell to something that checks your users for access to a system:

   couch:78392748483:30:30:Alva L. Couch:/u/f/couch:/usr/local/bin/check-em-out
  

  where check-em-out contains:

   #! /bin/csh -fb
   
   # check out whether person is paid up
   /usr/local/bin/paid-up $USER
   if ($status==0) then
       echo "welcome to loan-shark-land"
       exec /bin/tcsh
   else
       echo "pay up or don't get in, bozo\!"
       exit 0
   end
  

Price of Liberty

• ... is eternal vigilance.
• No matter how well you protect your password file, users are still typing passwords in the clear somewhere.
• Last successful EECS attack: sshd trojans:
  • replace sshd with a new daemon that saves plaintext passwords.
  • daemon also listens on a high-numbered port for a command to dump its guts.
  • collect data over time, then dump all to the happy hacker.
• Note that:
  • encrypting the data over the network didn't help.
  • storing the passwords in encrypted form didn't help.
  • because the hacker got access to the unencrypted forms.
  • Similar strategy: hack the client ssh.

Risk:

• passwords sent in clear text can be snooped (captured).
• This makes you susceptible to replay attacks in which a cracker simply plays back your username and password.
• crackers can use this to get access to normal or even root accounts
• can use these accounts to:
  • impersonate users
  • send spam
  • harass others
  • obtain further account privileges.

Approach: One-Time Passwords (OTP)

• each password is used ONLY ONCE.
• if you sniff it, this tells you nothing.
• so you can utilize clear channels and no one's the wiser.
• early approach: pre-PKI.

OPIE: One-Time Passwords in Everything.

• replaces:
  • /bin/su: switch-user command.
  • /bin/login: login program type Username and Password.
  • /usr/sbin/in.ftpd: ftp daemon. with special versions that understand one-time passwords.
• backward compatible with:
  • normal /bin/login
  • Predecessor S/Key: uses same encryption and clients.

Idea of OPIE and S/Key (its predecessor)

1. write a function M that's difficult to reverse
   • Given A, easy to get M(A),
   • Given M(A), difficult to figure out what A was.
   • this is called a trapdoor function.
2. each user initializes the process by providing a password to a calculator on a local machine.
3. This password is hashed by calling M on it 100 times repeatedly. E.g.: s = M(M(M(M(...100 times...(M(M(p))...))))=M^100(p)
4. OPIE stores this value and the number of times M was applied.
5. When a user wants access, OPIE asks the user for the result of the 99th application of M, say q.
6. if M(q) = s, then the user is real, and we
   • store q as the new s,
   • decrease the count to 99,
   • repeat next challenge with new s and 99.

Why this works

• M is difficult to reverse.
• So having M^99(p) won't get you p, or even M^98(p).
• But if you know M^99(p), you can check whether M^98(p) is authentic!
• If it is, you can store M^98(p) and the next time, check it against M^97(p).

Inside OPIE

• OPIE's trapdoor function is the MD5 hash function (of your passphrase).
• MD5 is a cryptographically secure hash function (designed by Rivest, the 'R' in RSA). This means that:
  • It's easy to compute.
  • Given different A and B, it is very unlikely that MD5(A) will equal MD5(B).
  • Computing A from MD5(A) is computationally intractable.

Very clever OPIE features

• opie one-time passwords are actually 128 bit HEX numbers, e.g., dd363c5a2b90bb985d4dbeffd7c1b21f.
• OPIE observes that these are easiest to type if they're mapped into sequences of six two-to-four letter words! It uses a dictionary to do this.
• So your 'passphrase' is a sequence of 6 words!
• You can ask OPIE to precompute all your passphrases so you can print the list and take it with you.

Using OPIE:

• opiepasswd - start up opie

   # ./opiepasswd -c couch
   Adding couch:
   Only use this method from the console; NEVER from remote. If you are using
   telnet, xterm, or a dial-in, type ^C now or exit with no password.
   Then run opiepasswd without the -c parameter.
   Using MD5 to compute responses.
   Enter new secret pass phrase: 
   Again new secret pass phrase: 
   ID couch OTP key is 499 bl2366
   SOB TURN FORM GORE NOT CUFF
  

• opiesu - switch user ID

   blackhole{couch}64: opiesu couch
   otp-md5 498 bl2366
   couch's response: YARN ORB TEET MAE TOM GAIT
  

• opiekey - compute a passphrase to be used in opiesu, opielogin.

   blackhole{couch}72: otp-md5 498 bl2366
   Using the MD5 algorithm to compute response.
   Reminder: Don't use opiekey from telnet or dial-in sessions.
   Enter secret pass phrase: 
   YARN ORB TEET MAE TOM GAIT
  

OPIE limits

• each host has separate database
• no concept of network-wide authentication
• still susceptible to replay attacks if you use same passphrase and random number seed on two hosts!
• limited to 500 insecure logins before you have to renew your passphrase.

Very Clever: how to 'renew' your opie password in the clear

• login through an insecure host.
• have an OPIE calculator in hand, but not on the insecure or target host.
• Do an opiepasswd on the target host.
• It issues a new challenge.
• You calculate the response and type it.
• This re-initializes the process!

Watch out:

• Everything depends upon keeping the passphrase itself private.
• If you use OPIE's calculator through any insecure connection, you lose.
• Then a hacker can gain access to the passphrase, and thus become able to generate one-time passwords.
• If you have even one telnet session in your path of connections, you lose.

Other approaches:

• SecureID: carry a physical hardware device capable of generating an OTP.
• Avoiding re-authenticating a user.
• ssh: encrypt passwords and session using secure socket layer (public-key cryptography).
• Kerberos: do secure key exchange with a secure keyserver.

SecureID:

• Carry a calculator in your pocket(vest pocket, because it crushes easily).
• When you need to login, type your PIN on the card; it prints your password.
• Passwords are linked to time of day.
  • Window: when a password is valid.
  • Typically + or - 10 minutes.
• Passwords are authenticated by contacting a SecureID server
  • Proprietary software (NT-based)
  • `Hardened' against hacker attacks.

            userID, pass     userID, pass
     client --------> server ==========> SecureID
                                         server
            <--------        <=========
             allow or         yes or no
             deny
    

  • where <=> channels are encrypted and <-> channels are perhaps cleartext.
• Card designed not to be possible to reverse-engineer. Will literally `self-destruct'.

Trust

• Simplifying user authentication requires some form of trust.
  • in your channel of communications or
  • in some server that is hardened against attack.
• Most security systems function through transitive trust.
  • If A trusts B and B trusts C, then A 'should trust' C.
  • Strength: easy to describe trust arrangements.
  • Weakness: if someone compromises C then both A and B are compromised.

Hosts.equiv and .rhosts

• Simplest form of trust: 'we have the same users'.
• hosts.equiv: tells which hosts have the same users as you.
• .rhosts: personal file of hosts and accounts equivalent to you.
• If you have the same account name on another machine, and if your machine is listed in /etc/hosts.equiv on the other machine, then you can rsh or rlogin to that machine without password.
• Good news: under UNIX only root can initiate a request for this service, so users can't spoof it.
• Bad news: under MS/DOS and NT, users can spoof requests by supplying fake usernames!
• gaining access to a trusted account gives access to all hosts that trust it, through one or more transitive steps.
• rsh is so insecure that many admins turn it off by policy.

SSH

• session encrypted using public-key technology.
• This includes password.
• No snooping possible unless you can break the code.

Basics of Public-key cryptosystems (RSA)

• public key: something you broadcast to everyone.
• private key: something only you know.
• both 48-bit or 128-bit integers.
• symmetry of use:
  • anything encrypted with your public key can only be decrypted with your private key.
  • anything encrypted with your private key can only be decrypted with your public key.

Sending secure messages

• If you want to send something to another group, and make sure that only the intended target can read it, then
• Get their public key.
• Encrypt it with their public key,
• Send it to the them.
• They decrypt it with their private key.

Notation

• E(x,y) is the result of encrypting message x with key y.
• D(x,y) is the result of decrypting message x with key y.
• P is a public key. Q is a private key.
• M is a message.
• Note: D(E(x,P),Q) = D(E(x,Q),P) = x

Providing proof of authenticity

• If you want to prove that something's from you.
• Encrypt it with your private key,
• Publish your public key.
• Users can decrypt it only with your public key.
• Others can't provide anything your public key decrypts!

     encrypt        send           decrypt
   M ----> E(M,Q) --------> E(M,Q) ------> D(E(M,Q),P) = M
  

Providing secure messaging

• Encrypt it with the recipient's public key.
• They decrypt with their private key.
• No one else can decrypt it.

     encrypt        send           decrypt
   M ----> E(M,P) --------> E(M,P) ------> D(E(M,P),Q) = M
  

Doubly-secure transaction assures both authenticity and privacy

 source doc from you
    M
    |
    | encrypt with sender's private key (only sender knows) 
    v
 encrypted once to prove authenticity 
 E(M,Qs)
    |
    | encrypt with recipient's public key (published everywhere) 
    v
 encrypted twice to protect content 
 E(E(M,Qs),Pr) 
   ...
   ...send on internet
   ...
 encrypted twice to protect content
    |
    | decrypt with recipient's private key (only recipient knows) 
    v
 encrypted once to prove authenticity
 D(E(E(M,Qs),Pr),Qr)  = E(M,Qs)
    |
    | decrypt with sender's public key  (published everywhere) 
    v
 source doc to recipient
 D(E(M,Qs),Ps) = M

• Ps, Qs: Sender's public/private key pair.
• Pr, Qr: Recipient's public/private key pair.

Applying Public-key technology to encrypting sessions (ssh)

• Give every host a public/private key pair.
• Private keys are important so they're large (128 bits)
• This is too expensive for constant use.
• Solution: create a 'session key' that is used just for one session.
• Exchange session keys using host keys for initial encryption.

   starting up an ssl/ssh session (sketch) 
    client                                server
                                          
    accept server public key (clear)  <-- send public key to client
    generate 48-bit client session 
      public/private key pair
    encrypt client public session key 
      with server public key 
    send encrypted public session key --> decrypt client public session key 
                                            with server private key
                                          generate 48-bit server session 
                                            public/private key pair
                                          encrypt public server session key 
                                            with client public session key
    decrypt server session key        <-- send public server session key
      with client private session key
  

• At this point (without ever sending an un-encrypted message) we have the following situation:

    client:                                server:
    private client session key             private server session key
    public server session key              public client session key
  

• client-to server:
  • client encrypts with private client session key
  • server decrypts with public client session key
• server-to-client
  • server encrypts with private server session key
  • client decrypts with public server session key

Ssh limits

• requires custom client software: can't just utilize telnet.
• requires custom server software.
• can cost big $ for commercial users.

Ssh vulnerabilities

• ssh still assumes that 'client' and 'server' are relatively secure themselves.
• If you can get a server private key, you can impersonate the server.
• How to crack ssh (man-in-the-middle attack)
  • compromise a router close to the targeted host.
  • steal the ssh private key for a server.
  • redirect client request packets at a fake ssh host you create, running in promiscuous mode.
  • use your fake host as a proxy; send all packets from there to the real host.
  • snoop on ssh session, determine keys, sniff user password, etc.
• If you have the user's real password, you can impersonate them without a trace.

Public-Key Infrastructure (PKI)

• ssh stores public and private keys locally.
• Many times we need to store the public keys globally.
• Any mechanism for storing public keys globally is called public-key infrastructure or PKI.

Digital Signatures

• Often we want simply proof of authenticity.
• Simple strategy: report the hash of a thing encrypted with a particular private key Sig = E(M(x),Q).
• If you're the only person with Q, and you publish P, then you're the only person who can compute Sig.
• Proof of authorship:
  • Look up public key for the advertised author using some form of PKI.
  • Compute M(x) and compare with D(Sig,P).
  • If they're the same, then the author is legitimate.

Digital certificates

• So far we only need one PKI server of public keys.
• This doesn't scale well, as we would need to keep track of all the servers.
• Digital certificates are a method of using transitive trust with PKI.
• Certificate: a document that expresses an identity
  • Name, Address, domain (e.g., eecs.tufts.edu).
  • expiration date.
  • Public/Private key pair.
• Signing a certificate C: compute Sig = E(M(C),Q) for some private key Q. Append to certificate file.
• Can have multiple signatures for one certificate.

Kinds of certificates

• Personal: identifies an individual
  • can potentially be used in the future to sign legal documents.
• Server: identifies a computer
  • avoids server spoofing.

Here's how this works

• Suppose you have a certificate.
• It isn't worth anything unless some `certifying authority' (CA) has signed it (IBM, Verisign, etc).
• Purpose of a CA: to insure legitimacy of identity of a certificate holder.
• Transitive trust: if CA #1 trusts CA #2, and CA #2 signs my my certificate, then CA #1 trusts my identity.
• I could, e.g., set up a CA within EECS and try to talk someone at a real CA into accepting it. Fat chance.
• Altogether too much money in being a CA.

The heartbreak of certificates

• I run our secure web servers using a 'self-signed' certificate.
• If I follow the instructions, I have to 'unlock' my certificate private key each time I start the web server by typing a 'passphrase'.
• So I type a null passphrase so my web servers will reboot without me.
• So my private key is exposed.
• So my site isn't really protected by certificates; they just enable encryption.
• Creating a certificate: openssl (formerly ssleay)

Kerberos

• basic assumption: all servers and clients are insecure.
• strategy: direct all authentication requests to a more secure server that you protect galliantly.

Kerberos operation

• user uses 'klogin' to initiate a key exchange with a secure Kerberos authentication server (similar to ssh key exchange above).
• As a result of key exchange, user receives a 'ticket-granting-ticket'.
• When a user requests service, each request sent to a secure authorization server includes the ticket-granting-ticket.
• If the ticket-granting-ticket is OK, the authorization server responds with a true ticket for the service.
• real servers accept the true ticket as proof of authenticity.

   user                                        
            user name, password hash
   klogin -----------------------------------> authentication 
            ticket-granting ticket (TGT)          server
          <-----------------------------------
   
   resource TGT + resource request 
   needed  ----------------------------------> authorization
   (e.g.    resource ticket (RT)                  server
   NFS)   <-----------------------------------
  

  Once initial negotiation is complete, ask for resource

         req+RT            req+RT
   mount ------> resource -----------> authorization server
         granted  server   yea or nay
         <------          <------------
  

Kerberos limits

• must run extra servers.
• can't run anything else on them.
• must run redundant servers in case things go down.
• servers must be especially secure: if compromised everything gets compromised.

Problem: root is too powerful

• giving out root privilege is dangerous
• but it's too much bother to do things for others.
• Normal users can't help themselves.

Readers-Writers problem

• If two entities try to WRITE the same file at the same time,
• the LAST CLOSE wins! (race condition)
• Suppose two people edit /etc/passwd at same time!
• One is going to lose => lose integrity (you no longer know what's in your system).

Risks

• normal people can make mistakes as root and destroy systems.
• normal people can expose the real root password to sniffing.

Solution: power broking

• sudo: limited root privilege broker.
• allows a limited number of users to do some things as root
  • clearing printers.
  • breaking locks on screens.
  • bumping students out of labs.
• without giving anyone the real root password.

Using sudo:

• sudoers: a file describing access rights contains
  • host aliases:

     Host_Alias      SERVER=andante,largo,allegro,conbrio
     Host_Alias      LAB_CLIENT=c1,c2,c3,c4,c5,c6,c7,c8,c9,c10
     Host_Alias      SUNS=SERVER,LAB_CLIENT
    

  • user aliases:

     User_Alias      FACULTY=couch,dwk,ablumer,margo
    

  • command aliases:

     Cmnd_Alias      PRINTING=/usr/lib/lpsched,/usr/sbin/lpshut,/usr/bin/cancel
     Cmnd_Alias      REBOOT=/usr/sbin/reboot,/usr/sbin/halt,/usr/sbin/shutdown
    

  • Command patterns

     couch           blackhole=REBOOT
     FACULTY         ALL=PRINTING
    

• To utilize a command, simply type

   sudo /usr/sbin/reboot
  

  sudo asks you for your own password,

   Password: 
  

  and if correct, does what you wish!

Transitive Trust

• How can one get access to multiple resources.
• One answer: transitive trust
  • If you've authenticated yourself on one machine,
  • and the other machine trusts this one,
  • then trust you on the other machine.
• Pros: convenient.
• Cons: hacker who compromises a trusted host compromises the network.

Ways of achieving transitive trust:

• .rhosts: list of hosts on which a user has the same account.
• .ssh/authorized_keys: list of keys authorized to login to this host.
• In all cases, something in the account replaces something you know.
• If that something becomes widely known, anyone can get, e.g., root access.