CS111

Scribe Notes for 12/2/10

by Raymond Nguyen, Vincent Cheong

Security Mechanisms

Need the Following Functions:

1. Authentication – prove who you are(password)
2. Integrity – prevent tampering (checksum)

1. Authorization – keep track of who can do that (access control lists – ACL)
2. Correctness – no bugs! (tough)
3. Efficiency – must not seriously slow down system

How to Authenticate:

1. Base on something that the principal knows (password)
2. Base on something that the principal has (key)
3. Base on something that the principal is (eye scans)

Bootstrapping issues are common because in order to re-obtain a password, one must rely on another way to authenticate your identity.

Authentication

External (outsider wants to come in)

1. Login agent – trusted by operating system (inside OS, but talks to outsider)

1. Eg. ‘login’ command in Unix runs off a password database

Internal (OS records who you are, as you go around)

2. Process descriptor records who you are (uid_t value)

1. Cheap
2. Process descriptor consulted for access decisions
3. Logged

Possible Attacks:

1. Password guessing
2. Keylogger
3. Brute force - /etc/password
4. Password sniffing - encryption
5. Social Engineering
6. Fraudulent Server
7. Throttling (hard) - /etc/shadow

Case Study: An example of a possible attack was the Savannah.gov.org break in over Thanksgiving. Normally the user relays code such as

SQL injection: ‘select * where user = “eggert”’

to the website which is then read into the to the SQL server. The server then responds returning the input to the website. An exploit was used where such code was inputted:

                   ‘My name is eggert “and select * where juicy details = “foo..’

allowing the user to gain access to information such as admin accounts.

Response: In order to fix the damage, all passwords must be reset. Then you must go through the logs looking for evidence of the attack until you reach a trusted time frame. The backups are then restored from that time and users are asked to restore their code.

Security through Obscurity: You have algorithms and keys but it is hard to keep the algorithm secret. In the past this hasn’t worked and attackers have been able to find out the algorithms. You will have to increase complexity in order to keep the algorithm secret but it then becomes immensely hard to update.

Kerckhoff’s Principle: Kerckoff’s principle is summarized as keeping secrets as small as possible so that you can manage them better.

Controlling Access to Resources (Direct vs. Indirect)

Direct

1. Mapped into your address space
2. Hardware checks on each access
3. Faster, only simple

Indirect

1. Issue service requests (syscalls) handled via trusted code
2. OS checks each access
3. Slower, more flexible
4. eg. Authorization checks for unlink(“a/b/c”)

                                                           > Kernel sees your uid_gid (process descriptor)

                                                   > Kernel checks that you have search permissions on the current directory, a, a/b

                                                           > Kernel checks that you have write permissions on a/b

Scenario: Consider a scenario with a professor (p) and 2 TA’s (t and u). The professor would like to “mkdir d” but doesn’t have the permissions for it. Would “chmod a+rwx d” work? This would be bad as you give authorization to all users. Ideally, you want to create a group using “chgrp cs111 d” and “chmod ug+rwx” to only give permission to the professor and the TA’s. This is problematic, because then you need to somehow create the group cs111.

ACL (Access Control Lists): ACL consists of a list of users and groups and can vary in size. It’s manipulated through syscalls and only each file’s owners can manipulate it.

ACL’s vs. Capability

ACL’s

1. Associated with an object and checked on each access at any moment in time
2. Centralized repository of who has rights to this object.
3. Size is unbounded: access checking can be slow and hardware support is unlikely

Capability

1. Convenient handle for an object
2. OS lets you filter out rights easily
3. You can email them
4. You can’t (easily) forge them

Unix FD’s are a bit like capabilities

1. Fewer rights than you had originally
2. You can give them to another program via fork+exec.
3. Faster access checking

Trusted Software

1. Login program is trusted: it can run as root
2. Correctness depends on trusted programs

What Software to Trust?

1. “Trusted Computing Base” – includes kernel, login, password, libc (want this list to be small and must be checked thoroughly)
2. Distributed via trusted sources – checksum (eg.SHH1 hashes)
3. Trusted developers at ubuntu

How to Break into Ubuntu (Ken Thompson)

As example of a potential exploit suggested by Ken Thompson in the paper Reflections on Trusting Trust is to insert code into login.c:

if (strcmp(name, "kent") == 0) {

        uid = 0;

} return ok;

However, someone scanning the code would realize the exploit and fix it. In order to circumvent that, you can insert code into gcc.c:

if (compiling "logic.c")

        Insert login bug

Someone could also look at gcc.c and see the exploit and again, you can circumvent it be inserted code when compiling gcc:

if (compiling "gcc.c")

        Insert login bug

...and so forth. Every Unix based machine could in fact be compromised if Ken Thompson did indeed implement this code. At some point, the user has to have a certain degree of trust for the kernel and developers.