CS 111 Scribe Notes

6/7/2007 CS 111 Scribe Notes Security Continued:
Last lecture we went over:
Authentication
Integrity
Authorization
Auditing

Authorization

Try and keep track of everything everyone is allowed to do
Think about it as a 3 dimensional space
axes are:
principals/actors/users/subjects - people "using the system and can do stuff"
objects - things that can be acted upon.
actions/operations - what they're trying to do with the object

In theory, we could set things up this way, as a 3 dimensional bitmap of permissions But, its a hassle to support arbitrary generality here.
For two reasons:
1. Amount of storage and work here grows roughly with the square of the size of the system.
2. Tough to make sure it's right. Hard to maintain. Might make a mistake, flip wrong bit.
In practice, this scheme is too complicated to set up.

People look for simplifications
You still have to consult the subject, object, and action, to find out if allowed
But, it's not quite that general

We want it simpler, easier to implement.
How do we do that?

Unix model (classic)

Associate about 12 bits for permissions, stored in inode.
9 of them are pretty straight forward.They come in groups of three.
Lowest order 9 are ordinary, divided into 3 groups
[special, 3 bits] [owner/user, 3 bits] [group, 3 bits] [other, 3 bits]
Each group of 3 bits are for read, write, execute.Lowest 9 bits look like rwxrwxrwx.
Common patter is 755, rwxr-xr-x, user can write, all others can read and execute
Not all values make sense here...
---rw--w- says user can not touch file, group can read and write, others can write(silly).
Generally we expect other bits to be a subset of group, which is a subset of user permissions.
special bits: setuid, setgid, sticky bits. These are messy, used to address ceratin problems.
for a regular file:
if you execute a file marked setuid, that program doesn't run with your permissions, it runs with permissions of file owner.
if file is owned by root, marked setuid, then program will always run with root permissions.
Its a way of controlled export of superuser's powers. Setuid programs are an admission that we can't handle all of the security problems in unix, because it doesn't let you do stuff you should be able to do.
In practice, many systems need this kind of capability. theres a security model, and then there are exceptions because, if enforced too tightly, the security model becomes a straightjacket.
setgid is the same, except with a group...
sticky bit was originally for optimization. It meant that when you exit the program, leave it in swap space because someone might want to use it again soon.

for directories, these bits are entirely different:
the sticky bit means that only the owner of a file can remove or delete a directory entry. Normally, you just have to be able to write to the directory . But with sticky bit, you have to be owner of the file too. This is due to /tmp that everyone has to be able to write here, but anyone can remove files too. /tmp would be totally insecure were it not for the sticky bit.
setgid bit affects new files created in the directory. If set, newly created files belong to the same group that the directory does. This encourages sharing more than default would without this rule, files would all be in separate groups.
Example:
courses and quarters need to be accessed by appropriate people, profs, TA's
/class/spring07/cs111
/class/spring07/cs131
One approach, create a group "cs111_spring_07" containing prof, TAs
But we have a group for each directory
UNIX permissions feel forced...not designed for this application
Instead, department utilizes Access Control Lists (ACLs)
Used starting in Windows NT, Solaris, some Linux
Associates with each file a list of which users and groups can access the file.
For a file, there is a list of people and their permissions. Granted on a per-user basis.

if we invoke the following
$ getfacl		# get file access control list
	user::rwx
	group::r-x
	other::r-x
$ setfacl -rm gropu:tas:rwx	#give TAs rwx permissions.

$ sudo umount /dev/bar

This means please execute umount as root, but then go back to being myself again. You dont want to be root very long because root is really powerful and you'll break things quicker. The goal of sudo is to minimize priveliges.

Sometimes, access control lists grant too much power. If a TA needs grade access and research project access, they may copy grades to where research users can see them.
Another approach that is gaining popularity in security community is role based access control (RBAC). Grant access based on role that user is currently assuming. Users assume only one role at a time. Now, this person is a TA with TA permissions, but then they assume research assistant role, losing TA rights. You can even have roles on a per-process basis. Associated with operations and not just objects.
One operation is "unlinking a directory". In traditional unix, only root can do it under solaris 10, you can give up this ability.
Also, linking to a file you dont own.
Only requirement is that you are able to "see" the file (by searching any other directories.) why is this a problem?

/bin/sudo (setuid root)
if admin fixes bug
	/bin/sudo1
	rename("/bin/sudo1", "/bin/sudo")

fixed? no! because attacker can link the buggy /bin/sudo to /home/attacker/bin/sudo and continue to use it.
Need to keep scale in mind.
For personal desktop, you probably don't need more than "normal" and "root" access
For University of California, even ACLs and RBAC might not be enough. It gets really complicated with everyone needing to do all different things, and no more.

Policy is authorization
Mechanism is authentication
based on : who the principal (user) is:
classic example is retinal scan
assumption is no two people have same eyes, people dont swap eyes.
something the principal knows:
password
problem with passwords is that they can be guessed or snooped.
something the principal HAS:
physical key
Typically you START with who you are, and then they give you one of the other things (password or key).
General design principal for implementing cryptographic authentication:
minimize what has to be secret
Protocols you use should not be secret
Algorithms should not be secret (then they have fewer reviewers)
-keys are the only secrets
Kerchkoffs (~1880)

Authentication building blocks

Cryptographic hash functions
SHA1(M) = H //M is message
It returns H, a small, fixed size quantity (160 bits)
If an attacker is told H but not M, he or she cannot guess any value M such that SHA1(M) = H
To reverse engineer it, you have to run through 2^160 random messages, then you have a half chance of running across the original message.
Symmetric encryption (eg triple-DES)
Sender and recipient share a secret key. So going to and from encrypted form is easy. But without sercret key, computing message from encrypted version is hard. If you have original and encrypted message, computing the key is hard. In many protocols, common data (time of day) is encrypted, so attacker might know original message.
Third approach is public key encryption
asymmetric
you have secrets you keep to yourself.
you dont just have a message M and key K
you have message M and two "flavors" of same key
U is public key
V private key
Basic idea: Given M and someones U, you can encrypt it easily but, you need their V to decrypt it easily. Decrypting with encrypted message and public key is hard. Getting private key is also hard.
+ no shared secrets to maintain
- tends to be more expensive
= key distribution is still tricky.
What if you are given attackers public key now you just sent your message to THEM

simple authentications, shared secret K
A: {I'm Alice}[K]
B: OK

Suppose you are an attacker who can eavesdrop and send messages replay attack is possible

A: I'm Alice
B: Prove it, here's some random bits
A: {proof: random bits}[K]
B: okay

Later if attacker replays authentication, it doesn't work with new random bits. If attacker knows protocol, attacker can spoof packets with A's IP address now that A is authenticated. Technical term for random bits made up for the occasion is a "nonce"

Multiphase authenticatoin (public key)
A: {Nonce[A] + Hi I'm Alice} [Ub]
B: {Nonce[A] + Nonce[B]} [Ua]
A: {Nonce[B] + session key} [Ub]
	K for some shared secret encryption
	might be 150 bits, smaller, faster

Ordinary session packets use K plus a hash function (say SHA1) K keeps data secret, SHA1 makes sure packet hasnt been tampered with. Common algorithm is HMAC
{SHA1(K^pad1) + SHA1((k^pad2) + M);}[K]
20-25% overhead for checksum but high reliability

Secure Shell
	form users viewpoint
	client: ~/.ssh/id_rsa.pub	//public key
		~/.ssh/id_rsa		//private key
		~/.ssh/known_hosts	//table of (ip address, server public key)
server: ~/.ssh/authorized_keys		//list of public keys that are allowed to connect.

ssh_keygen uses random bits to make private and public key pair
You can setup tunnels with ssh -l server.
Basic idea behind a tunnel is as follows:

client				server
ssh process			ssh process
with Apache:80

Client can say, "if server gets requests on port 80, send them to me."
This idea is bidirectional
ssh tunel = virtualized network
Its a way of escaping whatever bizarre rules your network has.
This gets ugly fast since everyone needs to keep their ssh folders everywhere they might go

IPSEC:
oriented toward big guys
+ key management
- huge system, hard to get into
Foolproof way to break into a system based on unix, linux, whatever with a catch.
Reflections on trusting trust
http://www.acm.org/classics/sep95
Get a copy of login program. Modify code so it really does.
attack:
"if username == ken, OK."
convince everyone to use this login program.
The catch is that someone will read that and get rid of it.
So you look at the source code to gcc.c

	modify so that
	attack B
	"if source file == login.c then generate this attack above"
	convince everyone to use this gcc

but, someone will read gcc source code and fix that.

so, write gcc.c'
	if source == "login.c" generate attack code
	if source == "gcc.c" generate attack B code
now compile gcc this way, throw source away

give them modified gcc binary and original gcc source code.
if youre doing security you must have a trusted computing base. you HAVE to trust somebody
you want to minimize this group, but it exists.
you have to know what's in it.