New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Computer Security

by: David Mayert

Computer Security CSE 643

David Mayert
GPA 3.74

Wenliang Du

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Wenliang Du
Class Notes
25 ?




Popular in Course

Popular in Computer Engineering

This 9 page Class Notes was uploaded by David Mayert on Tuesday October 20, 2015. The Class Notes belongs to CSE 643 at Syracuse University taught by Wenliang Du in Fall. Since its upload, it has received 68 views. For similar materials see /class/225560/cse-643-syracuse-university in Computer Engineering at Syracuse University.

Similar to CSE 643 at Syracuse


Reviews for Computer Security


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/20/15
CISCSE 643 Computer Security Syracuse University Capability l CapabilityBased Access Control 1 An Analogy Bank Analogy We would like to use an example to illustrate the need for capabilities In the following bank example we will discuss two access control mechanisms access control list ACL and capability We will compare the pros and cons of these two different mechanisms Example Alice wishes to keep all of her valuables in three safe deposit boxes in the bank Occasionally she would like one or more trustworthy friends to make deposits or withdrawals for her There are two ways that the bank can control access to the box 0 The bank maintains a list of people authorized to access each box 0 The bank issues Carla one or more keys to each of the safe deposit boxes 0 The ACL Approach Authentication The bank must authenticate Bank s involvement The bank must i store the list ii verify users Forging access right The bank must safeguard the list Add a new person The owner must Visit the bank Delegation A friend cannot extend his or her privilege to someone else Revocation If a friend becomes untrustworthy the owner can remove hisher name 0 Capability Approach Authentication The bank does not need to authenticate Bank s involvement The bank need not be involved in any transactions Forging access right The key cannot be forged Adding a new person The owner can give the key to other people Delegation A friend can extend his or her privilege to someone else Revocation The owner can ask for the key back but it may not be possible to know whether or not the friend has made a copy 0 Alice in a hostile environment Alice does have a social life and she often go to bars with her friends some of which might be evil Therefore Alice can get drunk when people get drunk they might do things or make mistakes that they regret to do Which approach ACL or Capability is better to deal with this situation A With the capability approach Alice can choose not to carry the keys with her when she goes to drink This way even if she get drunk she cannot open the safe deposit box In the ACL approach there is no such kind of protection This kind of protection by the capability approach exempli es the leastprivilege principle March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 2 Alice often sends her employees to carry out tasks for her These tasks involve going to the bank several times opening several deposit boxes However the outside environment is quite hostile the employees might be kidnapped at any point of time Kidnaper can then force the employees to retrieve the valuables from the deposit boxes Most employees will not resist if kidnapped Which access control approach can better protect Alice s valuable properties A With the capability approach employees can destroy the keys that will not be needed by the ongoing tasks Alice still has a copy of all the keys This way even if the employees are kidnapped the damage can be reduced to the minimum This kind of protection is dif cult to achieve by the ACL approach 2 Capability Concept 0 The capability concept was introduced by Dennis and Van Horn in 1966 quotA capability is a token ticket or key that gives the possessor permission to access an entity or object in a computer system c Intuitive examples A movie ticket is a capability to watch a movie A key is a capability to enter a house 0 A capability is implemented as a data structure that contains I dentz er addresses or names eg a segment of memory an array a le a printer or a message port Access right read write execute access etc 0 Using capabilities Explicit use you have to show your capabilities explicitly This is what we do when we go to movie theaters we show the doorkeeper our tickets The following is another example that is quite common when a program tries to access a le PUT filecapability quotthis is a recordquot Implicit use there is no need to show the capabilities but the system will automatically check whether one has the proper capabilities An analogy to this would be having the theater door keeper to search your pockets for the right tickets Although the approach is awkward in this analogy it is quite common in operating systems The capabilitylist method basically uses this approach Namely each process carries a list of capabilities when it tries to access an object the access control system checks this list to see whether the process has the right capability Unlike the explicit use approach with this approach processes or the programmers who write the programs do not need to gure out which capability should be presented to the system Comparison The implicit approach is less ef cient especially when the capabilitylist is long However it might be easier to use because unlike the explicit approach capabilities are trans parent to users therefore users do not need to be aware of the capabilities March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 3 o The identi er of capability can be many things including users processes procedures and programs Capability on Users Users are more persistent identi ers Its capability can be stored in les Capability on Processes Processes are not persistent identi ers they usually obtain capabilities dynamically Capability on Procedures 1 Caller and callee can have different capabilities 2 Most capabil ity systems go a step further allow each procedure to have a private capability list Capability on Programs Giving capabilities to programs can achieve privilege escalation and downgrading Example Privileges in Trusted Solaris see the case study on Trusted Solaris SetUID programs are a special case SetUID programs have the root capability 0 Examples of capabilities implemented in LIDS Linux Intrusion Detection System CAPCHOWN override the restriction of changing le ownership and group ownership CAPDACREADSEARCH override all DAC restrictions regarding read and search on les and directories CAPKILL the capability to kill any process CAPNETRAW the capability to use RAW sockets CAPSYSBOOT the capability to reboot 3 Capability Implementation 0 Where should capabilities be stored Capabilities are critical to system security Once a capability is issued to a user the user should not be able to tamper with the capability In a protected place Capabilities can be stored in a protected place Users cannot touch the capability they use capabilities in an implicit manner In kernel this approach is adopted by the Capabilitylist approach in which the capability list is stored in the kernel eg in the process data structure Users cannot modify the contents of any capability because they have no access to the kernel Whenever users need their capabilities the system will go to the kernel to the capabilitylist Tagged architecture the capability can be saved in memories that are tagged as readonly and useonly In an unprotected place In some applications users may have to carry their capabilities with themselves When they request an access they simply present their capability to the system This is an explicit use of capabilities How to prevent users from tampering with the capability Because permissions are en coded in the capability if users can tamper with the contents of a capability they can gain unauthorized privileges The protection can be achieved using cryptographic checksum the capability issuer can put a cryptographic checksum on the capability eg digital signature Any tampering of the capability will be detected March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 4 This approach is widely used in distributed computing environments where capabilities need to be carried from one computer to another therefore relying on kernel to protect capabilities is infeasible Hybrid Approach users can use capabilities in an explicit manner but the capabilities are stored in a safe place The real capabilities are stored in a table which resides in a protected place eg kernel Users are given the index to these capabilities They can present the index to the system to explicitly use a capability Forging an index by users does not grant the users with any extra capability 0 Basic Operations on Capabilities Create capability a capability is created for a user or assign to a user Delegate capability a subject delegates its capability to other subjects There are many interest ing features related to delegation Expiration time specify the lifetime of a delegated capability Propagation control specify whether the users who get a capability via delegation can further delegate the capability Revoke capability a subject revokes the capabilities it has delegated to other subjects The implementation of revocation in general is a dif cult problem The followings are two common revocation schemes Approach 1 Have each capability point to an indirect object When revoking a capability we can simply delete the indirect object Approach 2 Use a random number The owner can change the number A user must also present the number in addition to the capability used in Amoeba The above two approaches do not allow selective revocation Attach an expiration time to a delegated capability can achieve automatic revocation Enable capability a subject enables a disabled capability Disable capability a subject temporarily disables a capability Delete capability a subject permanently deletes a capability It should be noted that disabling a capability is different from deleting a capability They are both useful to achieve the leastprivilege principle When a capability will not be needed anymore by a task eg a process this capability should be permanently removed from from the task This way even if the task is compro mised to execute malicious code the code cannot use the capability When a capability will still be needed later but will not be needed by a subtask eg a pro cedure within a process the capability should be disabled When the capability is needed it can be enabled It should be noted if the task is compromised to execute malicious code disabling capabilities does not help at all because the malicious code can enable the capa bility However if the task is compromised through other ways ie no malicious code is executed disabling capabilities can reduce damage March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 5 in srcfsfproch struct fproc Process Table struct filp fpfilpOPENMAX the file descriptor table struct filp Filp Table modet filemode RW bits telling how file is opened int filpflags int filpcount how many file descriptors share this slot struct inode filpino pointer to the inode table offt filppos Figure 1 File Descriptor Table Data Structure 4 Case Study Using Capabilities for File Access It is widely known that most Unix operating systems use Access Control List ACL as their basic access control mechanism however it is less well known that the capability concept has also been used in most Unix operating systems for a long time If you do not believe this look at the following program the program is executed by a normal user 1 f openquotetcpasswdquot quotrquot 2 readf buf 10 3 writef buf 10 Before the following statement is executed the root modifies the permission on etcpasswd to 600 ie normal users cannot read this file any more 4 readf buf 10 Because the etcpasswd le has a permission 644 normal users can open the le for read So the statement in Line 1 is successful This access control decision is based on ACL Now look at Line 2 and 3 We know that Line 2 will succeed but Line 3 will fail obviously there is an access control on both read and writ e Is the access control based on ACL If your answer is yes then answer the following question will Line 4 succeed orfail Line 4 is carried out after the access control list on the passwd le is modi ed If the access control in Line 3 is based on ACL the read operation should fail However interestingly the program can still read from the passwd le There is one logic conclusion we can make the access control decision for read are not based on ACL Then what is it based on It is actually based on capability 0 File descriptor is an application of capability When a le is open a le descriptor is created and stored in the f ilp table Figure 1 Each process has a f ilp table which is stored in the kernel space protected The userspace application is given the index of the le descriptor we often call this index the le descriptor but actually it is just an index to the real descriptor March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 6 write5 buffer size File Descriptor Capability 77777777 N Irnode Address file descriptor table for each process Figure 2 File Descriptor Table 0 The f ilp table is actually a capability list It contains a list of le descriptors Each le descriptor contains a permission part that describes what the process can do to this le the le descriptor also contains an identi er which is the address of the le s I node Figure 2 0 Basic capability operations Create capability a capability is created via the open system call Whether a process is allowed to create a capability depends on another access control mechanism the Access Control List ACL Namely the ACL of the le will be checked to decide whether the process can open this le If yes a capability will be created This interesting example demonstrates one type of coordination between ACL and capability Delete capability a capability is deleted via the close This system call will remove the corresponding capability from the f i 1p table The other operations such as delegation revocation enabling and disabling are not supported 0 Questions and Answers Q Can one forge a capability ie can one access a le without the legitimate capability A No The corresponding I node entry must be in the table Q Can we directly use fpfilp 10 A There is no use if fpfi 1p 10 is empty Users cannot modify filp table because the table is stored in the kernel space Q After a process opens a le permission is 744 it is owned by root the le s permission is changed to 700 by the root can this process still be able to read the le A Yes as long as the process uses the le descriptor to access the le The le descriptor is a capability that allows the process to access the le even after the ACL of the le changes 5 Case Study Using Capabilities for Memory Access 0 A process should only be able to access its own memory and the access must be authorized This access control is implemented mostly using capability See Figure 3 March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 7 Virtual segment number Element offset Segment Descriptor Capability Segment Physical Address Rights Length Memory S egment Figure 3 Conventional Segment Address Translation Segment Descriptor Table The segment descriptor table is a capability list which contains all the memory segments that the process can access The segment table can only be set by the system not by users Each descriptor speci es a block of memory that can be accessed using this capability it also speci es the process s permissions on this block memory read write and executable When a process tries to access a memory the address provided by the process is treated as a virtual address A virtual address contains an indeX that points to the capability in the segment descriptor table Using the capability the system will rst make sure that the process has a right to access the memory it then computes the real physical address of the memory This entire process is carried out by hardware support Otherwise you can imagine how many CPU cycles it will cost for a single memory access The 80x86 protection mode also uses this approach We will discuss this protection mode in more details in the later part of this course 0 Some capabilitybased system consists of a set of capability registers Programs can execute hardware instructions to transfer capabilities between the capability list and the capability registers Only the capabilities contained in the capability registers are effective This way a process can restrict its own capabilities to achieve the least privilege principle Another bene t is the performance Capabilities in registers can be processed faster than those stored in memory 6 Case Study Privileged Programs using Capabilities Oftentimes users need a special privilege to carry out a task eg changing their passwords In a capability based system privileges are often represented by capabilities Namely to carry out the task the users need some special capabilities However it is insecure to grant the users such capabilities because they might use the privileges on some other tasks It is desirable if we can ensure that the users only get the capabilities while carrying out the intended task the capabilities will be taken back from the users once the task is nished March 4 2009 CISCSE 643 Computer Security Syracuse University Capability 8 This objective is similar to what the Set UID programs are trying to achieve The basic idea is to assign the privileges to programs not to users Users gain the privileges if they run this program they will lose the privileges if the program nishes We will study how such mechanism can be implemented in a capabilitybased system I c When a privileged program is executed the capabilities will be effective For example if a program has a lereading capability it can read all les even if the user who runs the program is not superuser 0 Where do we store capabilities for programs Store the capabilities in a con guration le such as etc cap conf When system bootup con guration in this le will be read in kernel and saved in a capability array an approach used by LIDS ofLinux Store the capabilities in the program s I node When a process is created to run the program the process will be initialized with the program s capabilities c We should be very careful when writing these privileged programs The privileged program must contain the capability within the program so users can only use the capability for the actions intended by the program If there is a aw in the program users might be able to escape the containment with the capability Without the containment the users can use the capability for actions that are not intended by the program Consequently security breaches can happen Case Study Capabilities in Linux 0 Privileged programs using capabilities o Capability operations EnablingDisabling capabilities Deleting capabilities Delegation o Capability Bounding In Linux kernels 2211 and later system administrators can bound the capabil ities allowed on the system They can remove capabilities from a running system Once a capability has been removed it cannot be added back again until the system reboots Removing capabilities can be done through the lcap command lcap CAPSYSMODULE remove the capability lcap display the bounding set 0 Starting a process with a limited set of capabilities execcap capsysadmineip command 0 libcap library March 4 2009


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Janice Dongeun University of Washington

"I used the money I made selling my notes & study guides to pay for spring break in Olympia, Washington...which was Sweet!"

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.