Scribe Notes
Fall 2010, Week 10 December 3, 2010 Lecture
Eric Nam
Security Mechanisms
Require the following:
Authentication
Need to be able to prove who you are
e.g. password
Not perfect
Integrity
Need to make sure that data has not been tampered with
e.g. checksums
Not perfect: checksum collisions
Authorization
Need to be able to keep track of who does what
e.g. access control systems (ACLs)
Correctness
Need to have no bugs!
Bugs are exploitable so people would try to find them and use them
(This is tough to maintain)
Efficiency
Need to not seriously slow down system/performance with the above
Authentication
There are 3 different techniques to authentication:
1. Authentication based on something that the principal knows
Like a password
* The principal is the actor who is in charge and needs to be authenticated
2. Authentication based on something that the principal has
Physical key or card
3. Authentication based on what the principal is
Personal ID, appearance, eye scans and fingerprint scans
We do not want any false positives or incorrect appearances!
The best method is a combination of all of the techniques.
But there are also bootstrap issues; for example in order to obtain a SEASnet account the principal needed a card (Bruincard)
And needed to look like the person on the ID.
Handing out new keys based on old keys is very common as well.
Authorization
External: “Outsider wants to come in”
Login agent (like a bouncer) in the OS but talks to outsiders
Has to be trusted
E.g. “login” in UNIX
Possible attacks (assuming password database):
Password guessing / dictionary
Throttle logins to fix
Keylogger
Don’t let it happen (hard to fix)
Bruteforce storage /etc/passwd
Encrypted passwords kept in /etc/shadow and name, and is readable only to root
/etc/passwd contains public user stuff
/etc/shadow tries to protect for now and later
Password sniffing
Over the net
Encrypt the data over the wire (standard)
Social Engineering
DNS spoofing (phishing)
Fraudulent server
Internal: OS records identity as different access
Should be faster and cheaper than external authorization
Don’t have to do it
Permissions
Process descriptor records who you are during access (UID_t value)
Access decisions consultation
Is logged, only changeable for prviledged people/code
Case study: savanna.gnu.org break in on Thanksgiving
Occurred earlier but escalated
SQL injection attack
Takes
advantage of the SQL escape character syntax to inject code (queries)
Example normal query (correct syntax not guaranteed)
‘select * where user = “eggert”’
Example attack name to abuse the query
Eggert” and select * where juicydetails = “foo…
And more.
If the attack is done correctly the server will interpret it as a well formed query and it returns the data that would be returned for that query, so the attackers now have the juicy details.
During attack admin account with simple pw was hacked and used to insert security holes
To fix:
Reset all the passwords, since attackers theoretically have all of them
Look at changes in logs for evidence of attack and rollback to before that time from backups, we have to assume that the logs are not tampered with and can be trusted
Users resubmit changes they have put in since that time
Controlling access to resources
Direct-mapped into address space
Shared secret memory
Hardware registers
Hardware checks access (faster, but access control rules are simple)
Indirect-mapped – issue service requests (e.g. syscalls)
Handled by trusted code
OS checks each access (slower, but rules can be more complicated)
Let’s focus on indirect access and assume we have authization solved
e.g. authorization checks for unlink(“a/b/c”)
1. Kernel looks at your uid and gid in process descriptor
2. Check file permission of “a/b/c”
Check search permissions of “a/b/c” of current directory and a/ and a/b/
3. Check for write permission for a/b/ (don’t need to check c)
Will this work? Sample scenario:
Professors want to make a directory “d” available to the TAs but not students
“chmod a+rwx d”
We can’t do this because it would allow access to everybody, so we would have to call the sysadmin to make groups
Better Security Model
“Access Control Lists”
getfacl, setfacl
Permissions and names for access for each file, users or groups
ACLs need to be protected
Vary in size
In inode like permissions
Users cannot access them, only by syscalls can they be accessed
Only file’s owner can manipulate ACL
Default ACL for new file?
Unmask for ACLs is necessary
Each directory has a default ACL.
ACLs are in Solaris, Windows NT, and Linux
They can be thought of like this: a box with dots in it
The box is the system of ACLs and the dots are the allowed access and the blanks are the unallowed access.
This may not be a compact enough representation, and if we have 107 files with 103 principals and 103 actions, that would make 1013 dots which would be annoying to maintain.
ACLs need to keep it simple, which is what Capabilities are.
|
ACLs |
Capabilities |
|
∙ Associated with an object, checked on each access to object ∙ At any moment in time, ACL is a centrals repository for rights to an object ∙ Size is unbounded, making access checking slow ∙ Hardware support unlikely |
∙ Convenient handle for an object ∙ User must match what OS wants with checksum (generated fast, supported by hardware) ∙ They look like keys for object ∙ OS allows filtered rights easily ∙ Easily shippable over a network or even email since it is a bit pattern, but is also un-forgeable |
Capabilities are like credentials but more
UNIX file descriptors are similar to capabilities
Fewer rights than originally
Via fork-exec, rights can be given to another program
Fast access checking
UNIX uses both ACLs and capabilities.
Trusted Software
UNIX login is trusted
Can run as root
Setuid bit in permissions
0 for /bin/cat, 1 for /bin/login
Correctness depends on trusted programs
What software should be trusted? We can’t trust everything.
“Trusted Computing Base”
Includes kernel, login, passwd, libc
Want it to be small and simple for correctness (less holes)
These are distributed by a trusted method and checked with a SHA1 checksum hash
Here, Ubuntu devs are implied to be trusted
Ken Thompson attack
How to break into Ubuntu or any UNIX based system as outlined by Ken Thompson in “Reflections on Trusting Trust”
Change login.c such that there is a hole you can exploit
For example, if your login name is “kent” then give user root
To avoid getting caught, leave login.c as the original and instead modify the compiler compiling the code like gcc.
When it’s compiling have it insert the hole in login.c
If don’t want to get caught in gcc then do it for whatever is compiling gcc.c and so on
Since the original UNIX code is changed the hole lives on in its variants
Can avoid this by using different (not tampered compilers) or use gdb, but can you trust these?