computer science 4500 operating...

COMPUTER SCIENCE 4500 OPERATING SYSTEMS Module 11: File Systems and Security © 2017

Stanley Wileman

Last update: 4/18/2017

In This Module…

!  Files & File Systems !  Naming !  Attributes !  Access Methods !  Operations !  Directories !  Space Allocation &

Management !  Reliability !  Performance

!  Policies & Mechanisms

!  Security !  Intruder Actions

!  Privacy Issues

!  Generic Flaws

!  Security Attacks

!  Design Principles

!  Authentication

!  Protection Domains

!  Access Control Lists

!  Domains

© 2008 Stanley A. Wileman, Jr.

2

Operating Systems

File Systems == Storage Structures

© 2008 Stanley A. Wileman, Jr. Operating Systems

3

!  A file system is a storage structure. A storage structure is very similar to a data structure in that it provides methods (functions) to access a collection of data items, and a plan for how the data items are to be stored. Unlike a data structure – which assumes the data items are all resident in primary storage, a storage structure will typically make different assumptions about where data is stored. This naturally affects the functions that access that data.

File Systems – Where is the Data?


3.1

!  Data can be stored virtually anywhere and still be accessible by a file system. The “classical” media for file systems includes disks, tapes, and optical media (CDs, etc.). But modern file system can use primary memory as a file system, as well as storage devices accessible through a network. Some file systems (like the /proc file system in Linux) may even dynamically create data when it is requested!

File Systems – Naming the Data


3.2

!  Data collections in file systems are, somewhat expectedly, called “files.”

!  Almost all files are given symbolic names by which they can be accessed.

!  The policies and mechanisms for naming files differ among the various kinds of file systems, but the usual goal is to make the naming useful to the user and the applications.

!  The names are used to identify data collections. Once a collection has been identified, applications use a briefer identification, called a file descriptor or a file handle.

File Systems – Persistence and Reliability


3.3

!  In many cases it is expected that the data in files will be persistent – that is, the data will be retained even when the power to the computer system is removed, and become available again once power is restored.

!  Obviously that’s not the case with some media, like primary memory (unless dealing with old “core” memory).

!  Another important expectation is the persistent data will be maintained reliably. Almost by definition, reliability implies redundancy. And for file systems, redundancy means backups.

File Systems – Concurrency, Security


3.4

!  Most often it is expected that multiple processes will be able to access a file concurrently. That is, several programs may need to be able to access (either for reading, or perhaps both reading and writing) the same file at the same time. Think about web pages as an example.

!  The contents of files must also be protected from inappropriate access. Many different approaches to file system security have been developed, but new attacks on systems are also continually being identified.

File Naming Conventions


5

!  For ease of access, files are usually given symbolic names.

!  Naming conventions vary between operating systems. For example: ! MS-DOS only allows the “8-dot-3” format, with case being

insignificant, and blanks are not allowed. ! Modern UNIX systems allow 255 character names; case is

significant; blanks are allowed but not usually used. ! Windows NT allows 255 character names; case is not

significant; blanks are allowed and are frequently used.

File Extensions


6

!  Many systems use the last part of a file name, following a period, to indicate the type or expected interpretation of information contained in the file. For example: !  glurch.c is a C source program !  glurch.cpp or glurch.C is a C++ source program !  glurch.exe is an executable for DOS/Windows !  glurch (no extension) might be a UNIX executable

!  The use of file extensions is not required by all systems (e.g. UNIX), but application programs may still expect appropriate extensions. For example, glurch.exe may contain a C source program on a UNIX system, but the compiler will likely require it to be named glurch.c .

The Internal Structure of a File


7

!  The structure of a file may be imposed by the operating system, or it may be left completely to the application, but in many cases, both the operating system and the application impose some structure on a file.

!  For example, UNIX and MS-DOS impose no structure on files (other than directories), while files in the CP/M system are structured as sequences of fixed-length records. Applications decide how to interpret the data contained in files. IBM’s OS/390 has some file types which include control information not used by applications.

Typical File Types


8

!  Regular files, as their name implies, are those that contain user information (e.g. source code, data, executables).

!  Directories, or folders, are used to maintain the hierarchical structure of a filesystem.

!  Keyed files associate a unique key (usually a character string) with each record in a file.

!  Character special and block special files are used to model physical devices.

Regular Files


9

!  While the structure of regular files is usually entirely under the control of an application, many regular files do have common structure. For example: !  Text files contain printable characters grouped into lines, but

the line structure is usually system dependent (e.g. end each with line feed, or carriage return and line feed, or store a fixed number of characters for each line, or prefix each line with a fixed-size field specifying the line length).

! Object files and executable files must be properly formatted for the operating system (but there may be several acceptable formats).

! Database files must have the proper structure for the particular data base application.

Basic File Access Methods


10

!  Sequential Access: data is read or written in sequential order. This access method may be required for some devices like magnetic tapes.

!  Random Access: data can be accessed in any order. The data to be access is specified using a key (for keyed files), record number, or file offset.

!  Some systems classify files at creation time as sequential or random, but in most modern systems, all files can be randomly accessed.

File Attributes


11

!  Each file may have associated attributes which are not part of the file contents, but are used by the operating system for various purposes. For example: !  Security: owner, read-only, protection, locked !  Statistics: Creation, access, last modification time, size ! Descriptive: record size, file type, archive information

Typical File Operations

!  Create – make a new file

!  Delete – eliminate a file

!  Open – prepare a file for access from a process

!  Close – terminate access to a file

!  Read – retrieve data from an open file

!  Write – write data to an open file

!  Append – write data at the end of an open file

!  Seek – set the address at which the next read/write will operate

!  Get Attributes – retrieve file attributes

!  Set Attributes – modify file attributes

!  Rename – give a new name to an existing file


12

Operating Systems

Directories (Folders)


13

!  A directory (or folder) is a file that contains information about a group of files. Most operating systems do not allow processes to arbitrarily modify the content of directories, but rather provide special system calls to perform these changes. This guarantees the directory structure remains consistent.

!  Each directory usually contains a variable number of entries, with one entry for each file said to be “contained” in the directory.

!  Directories, themselves, do not actually contain other files.

Directory Entries


14

!  Each directory entry typically includes !  the name of a file !  file attributes (size, access rights, dates, etc.) !  location of the file’s contents (usually, the identification of

disk blocks)

!  In UNIX systems, each directory entry contains only a name and a pointer to another structure (the i-node) that contains all other information about the file.

Directories and File Systems


15

!  As noted earlier, many systems provide hierarchical ordering of files. This may be accomplished by allowing a directory entry to reference a regular file or a directory (as in UNIX or Windows), or by imposing structure on file names (as in MVS).

!  Some systems (like CP/M) only provide one directory per file system, and thus require each file name in that file system to be unique.

Path Names


16

!  With only one directory per file system, the file name is sufficient to identify a file.

!  With multiple directories, identification of a file is more complex, since several directories may have entries with the same file name. In these systems, a sequence of names, called a path, is used to indicate the sequence of directories leading to the desired file.

!  A special character is used to separate name components in a path. UNIX and OS X use ‘/’, MS-DOS uses ‘\’, and Multics uses ‘>’.

Absolute, Complete and Relative Paths


17

!  An absolute, or complete path begins with the separator character, and gives the full sequence of directories leading to a file.

!  Specifying each directory in a path is cumbersome, so the concept of a working directory, or implicit path prefix, is allowed.

!  A relative path, which does not begin with the separator character, begins at the working directory.

!  Each process has an implicit working directory specified at creation time, but a system call allows the working directory identification to be modified.

Path Name Examples


18

!  C:\DEVELOP\CS450\PROG2\PROG2.C (an absolute path name for MS-DOS)

!  prog2.c (a relative pathname) !  /home/stanw/prog2/prog2.c (an absolute

path name for UNIX) !  ../prog1/prog1.c (a relative path name)

The UNIX File Names ‘.’ and ‘..’


19

!  UNIX directories always include entries for files named ‘.’ and ‘..’.

!  The file ‘.’ refers to the current directory. !  The file ‘..’ refers to the parent of the current

directory. !  Example: the command ‘cp ../../file.c .’ will copy

‘file.c’ from the grandparent of the current directory to the current directory.

Typical Operations on Directories

!  Create (e.g. UNIX/DOS mkdir command)

!  Delete (e.g. UNIX/DOS rmdir command)

!  Rename (e.g. UNIX mv, MS-DOS ren command)

!  Link (e.g. UNIX ln) command

!  Unlink (e.g. UNIX rm command)

!  Opendir – open a directory to read entries

!  Readdir – read the next entry in a directory

!  Closedir – close a directory

!  DOS findfirst/findnext search functions


20

Operating Systems

Commands Functions

File Allocation Techniques


21

!  Disk space must be allocated for files, much like primary memory is allocated for executable programs. There are several primary techniques used: ! Contiguous Allocation – one contiguous group of disk blocks

are used. !  Linked allocation – multiple disk blocks are used, linked much

like a linked list. !  Linked allocation with indices – multiple disk blocks are used,

with their addresses recorded in an index. ! UNIX i-nodes – multiple disk blocks are used , with direct or

indirect pointers to each block.

Contiguous Allocation


22

Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 Block 8

File 1 File 2 File 3 File 4

2 3 1 2

Directory Entries (with location of first block, file name, and file size in blocks) Problems: file growth is difficult; initial estimate for file size may be too large.

Linked Allocation


23



2 3 1 2

Directory Entries

Problems: links take space in file blocks; random access is slow; processing file may require many seeks.

Linked Allocation with Indices


24



2 3 1 2

Directory Entries

Index (to next block)

7 4 5 Λ

6 Λ

Λ

Λ

Problems: index (e.g. File Allocation Table, or FAT in MSDOS) must be in primary memory for easy access; for large disks the index structure is huge.

UNIX I-nodes


25

!  In UNIX, each file has an associated i-node (or “information node”).

!  This relatively small, fixed-sized structure, is stored on disk, but is copied into memory when a file is opened.

!  The I-node contains all file attributes, as well as addresses of the first few blocks (direct pointers), and addresses of one or more blocks that contain additional block pointers (e.g. single indirect, double indirect).

!  I-nodes also contain a reference count to indicate the number of directory entries referencing it. A single file may have several names.

I-nodes and Block Pointers (Illustration)


26

Block 2

Block 1

Block 6

Block 7

Block 14

Block 15

Block 22

Block 71

Block 78 i-node single indirect block double indirect block

data block

"--

--I-

node

----#

(D

irect

Poi

nter

s)

Sing

le I

ndire

ct

Dou

ble

Indi

rect

I-node Advantages & Disadvantages


27

!  Advantages ! Only the i-node for the file being processed needs

to be brought into primary memory. ! Large files can be sequentially or randomly

accessed with few pointer lookups.

!  Disadvantage ! Blocks may still be scattered around the disk,

resulting in many seek operations.

Directory Implementation


28

!  Directory entries contain or point to a structure containing ! a file’s name ! attributes !  statistical information ! mapping information for disk block locations

The CP/M Directory


29

!  A CP/M file system has a single directory which is essentially a fixed-length array of directory entries. CP/M disk sectors (blocks) each contained 128 bytes. Each entry contains the following major fields: !  Deletion flag (contains hex E5 for a deleted entry) !  Filename and extension (11 bytes in 8+3 format) !  Extent (1 byte): to which group of 16 blocks does this entry refer? !  Block count (1 byte): how many 128-byte blocks in this extent? maximum is

16. !  Disk block addresses (16 bytes): where are the disk blocks?

!  A file will have one directory entry for each 16 blocks it contains. !  Since CP/M used only 7-bit ASCII characters in file names, as an

afterthought, the high-order bits in the filename were used to mark various attributes (like read-only, archived, etc.).

MS-DOS Directories


30

!  Each MS-DOS directory is also an array of entries, each containing the following fields: !  Filename and extension (11 bytes in 8+3 format) !  File attributes (1 byte): readonly, archived, etc. !  Date and time (2 bytes each) !  Address of first block in file (2 bytes): also identifies first block’s entry in

the File Allocation Table !  File size, in bytes (4 bytes)

!  Note that CP/M only records file size as a number of 128-byte records. MS-DOS records file sizes in bytes.

UNIX Directories


31

!  UNIX directories are also arrays of directory entries, each containing just these fields: !  Filename (255 character maximum in modern versions,

dynamically allocated as necessary) !  I-node number

!  I-nodes are stored in a separate array (or arrays) on disk, and the i-node number is an index to this array.

!  As previously noted, each i-node contains dates, times, owner, protection, attributes, and disk block location information.

Disk Space Management


32

!  Questions: ! How is disk space to be allocated to files? ! How is available disk space recorded?

!  Answers: ! A single disk block is never partially allocated to a file,

and certainly never partially allocated to multiple different files. The management overhead for such allocation would be excessive.

!  Files are very rarely required to be allocated in contiguous disk blocks (compare with the contiguous primary memory problems).

Internal File Fragmentation


33

!  Since files are allocated as a sequence of blocks, how much disk space should be allocated to individual blocks?

!  Remember internal fragmentation? On the average, half a block is wasted in sequential files (in the last block). Larger block sizes result in more waste due to internal fragmentation. However large blocks do reduce the number of seek operations required to access the file’s blocks.

Block Size Determination


34

!  Small block sizes waste less disk space, but potentially more seek operations and mapping information will be required.

!  A compromise is usually made between disk utilization and system efficiency. Block sizes of 512, 1K, 2K and 4K are in common use.

Free Space Management


35

!  Two major approaches: ! Free list: unused disk blocks are linked together, with

many pointers to unused blocks usually stored in a single block which is copied to primary memory.

! Bit map: essentially the same approach use as for primary memory, but since we don’t require contiguous disk regions, finding acceptable free space is much easier.

File System Reliability


36

!  What causes file system unreliability? ! Hardware failures (bad disk blocks, power glitches,

dropped laptops, floods, etc.) ! User mistakes (accidentally deleting a needed file) ! Failing to shut a system down ‘gracefully,’ so structures

in memory aren’t used to update disks. ! Errors in operating system algorithms!

Dealing with Bad Blocks


37

!  Use a spare block (usually on the same track) to substitute for the bad block.

!  Construct a ‘file’ containing all the bad blocks and never use that ‘file.’

!  Try to reconstruct data if only one or two bits is bad (using error correcting codes, ECC).

Improving Reliability


38

!  Backups are the main defense against file system failures.

!  As a general rule, the cost of recreating data produced since the last backup should always be less than the cost of doing another backup.

!  Backup media types include floppy disks, magnetic tape, removable disks (magnetic and optical), and additional disk drives.

File System Backups


39

!  Backup types: !  Image backups are block-by-block copies of a disk. These

allow easy restoration of a complete file system. !  Individual file backups allow individual files to be restored

more easily than image backups. !  Backup extents:

!  Full (complete): an entire file system is copied to the backup medium. This is usually done least frequently (perhaps annually, or monthly)

!  Incremental: only files that have been modified since the last backup are copied to the backup medium.

File System Inconsistency


40

!  File systems can become inconsistent for various reasons: !  blocks missing from the free list !  blocks listed as part of two or more files !  blocks listed as both free and as part of a file !  file size errors (more or fewer blocks than indicated in the

directory entry) !  directory errors (incorrect linking of directories to files, or files

to parent directories) !  Most systems include utilities to check for and, if

possible, correct inconsistencies (e.g. UNIX fsck, DOS chkdsk and scandisk).

Checking File System Consistency


41

!  Build a list of used blocks (by scanning information in directories). All remaining disk blocks should be unused. Compare the file system unused block list and the computed list.

!  Verify that each directory has appropriate entries for the “.” and “..” entries.

!  Verify that each block appears in the allocation for only one file.

!  Verify the reference count in each file and directory.

Disk Access Times


42

!  Reading from memory usually takes tens of nanoseconds (10-9 seconds).

!  Reading from disk usually takes tens of milliseconds (10-3 seconds).

!  Thus accessing a disk takes on the order of 106 times as long as primary memory access.

File System Caches


43

!  A file system cache, or a block cache, is just a portion of primary memory organized to keep copies of the blocks that have been recently used, and are likely to be needed in the near future.

!  A file system / block cache is almost always used to reduce the number of disk accesses used in accessing files.

Disk Block Access Algorithm


44

1.  Is the needed disk block already in the file system cache? If so, skip to step 4.

2.  Retrieve the requested block from the disk, or allocate an unused block and fill it with zeroes if necessary (for write operations to previously unused parts of files).

3.  Place the block obtained in step 2 in the file system cache, obtaining a free cache entry if necessary.

4.  Obtain data from the block (for read access), or modify the data in the block (for write access). Update file size, mark the block as “dirty” (for writes), and update other statistics as appropriate.

Obtaining a Free Block Cache Entry


45

!  If a free block cache entry is available, then it is used.

!  If no free block cache entry exists, then use an algorithm like FIFO or LRU to select one to replace. (Actually we typically try to maintain a minimum number of free block cache entries at all times, much like a page frame “slush fund”, so we don’t have to wait here.)

!  If the selected cache entry is “dirty” (that is, contains a modified block), write it back to disk before using it.

Observations about Performance


46

!  Block critical to file system structure (e.g. i-nodes), should be written as soon as they are modified. In MS-DOS, all blocks are written as soon as they are modified (this is called a write-through cache).

!  Even frequently used blocks should be written to disk periodically (if they were modified). The UNIX sync program writes all such blocks to the disk once every 30 seconds (on some systems).

Other File System Improvements


47

!  When obtaining free disk blocks, attempt to allocate blocks that are clustered together with other blocks in the same file.

!  Use rotational ordering to place blocks so less rotational latency will occur when accessing logically sequentially blocks.

!  Place i-nodes close to the data blocks they reference (this is the UNIX cylinder group concept).

Log-Structured File Systems


48

!  These systems (developed by John Ousterhout of TCL/Tk fame) maintain a log as a circular buffer on disk (and parts of it in memory) of updates to data and metadata (e.g. I-nodes).

!  The basis for this is the observation that with increasing primary memory sizes, disk operations would become mostly writes, since data being read would be mostly cached in memory.

!  A cache is maintained of the location of i-nodes in the log to enable fast access to them.

!  Writes to disk are done in large units to avoid much disk activity. !  The log may contain multiple versions of a file, and “old parts” need

to be culled, and valid parts moved when the log “wraps around.”

Policy vs. Mechanism


49

!  An important distinction must be made between the details concerning implementation of an operating system feature, and how or when that feature is to be used.

!  The term mechanism is used to describe implementation details of operating system features.

!  The term policy refers to how or when a feature is used.

Policy vs. Mechanism: Example 1


50

A linked list is used to implement the ready list for a particular system, but the scheduling is to be done using process priorities.

Here, the scheduling mechanism is to run the process at the head of the linked list. The policy is achieved by placing high-priority processes toward the head of the list.



51

An operating system built on the microkernel concept provides only minimal features in the kernel (e.g. context switching). All other features are provided by server processes running above the microkernel.

Here the microkernel provides the mechanism to switch between processes. The (software) servers determine when to switch (the policy). Of course it may be that the servers are also only implementing a policy that is determined elsewhere, so we have implementation done at several levels.



52

The system manager has decided to require all passwords to have at least an upper and a lowercase letter and a digit. Periodically the manager runs a program that disables all accounts with passwords that don’t meet this requirement.

The policy governs the formation of passwords. The mechanism by which the policy is implemented is the periodic checking and potential disabling of accounts.

Security


53

!  The term security refers to the overall problem. !  Protection mechanisms are the specific system

mechanisms used to safeguard information in the system.

!  There are two important facets associated with operating system security: ! Data loss or damage from malicious or accidental

actions. !  Exposure of private or privileged information by intruder

actions.

Intruder Action Classifications


54

!  Casual prying by non-technical users (e.g. browsing for unprotected files)

!  Snooping by insiders (e.g. running fake login programs)

!  Determined attempt to make money (e.g. trying to crack encryption of digital fund transfer mechanisms)

!  Commercial or military espionage (e.g. stealing entire computer systems or disks)

Privacy Issues


55

!  The term privacy refers to the policies governing the availability of information. Note that protection mechanisms are independent of, but may support, privacy policies.

!  Some typical privacy questions: !  Is electronic mail protected by law? For example, can I use my

AOL account to arrange for drug sales? !  Can an organization maintain records of your credit card

purchases to build profiles of what you’re likely to purchase in the future, and then sell this information to vendors of those commodities?

!  Can a university divulge your grades to potential employers?

Famous Security Flaws


56

!  UNIX mkdir: create i-node (as root), then change ownership. On a slow system, the user could make a link from the new i-node to the password file between the two system calls, leaving the user owning the password file.

!  TENEX password guessing. Passwords were checked one character at a time. Users could determine when page faults occurred, and by clever manipulation, could cause a page fault after every character was checked.

!  Logic Bombs and Back Doors: leaving code in systems that performs unwanted actions, or allows unauthorized access to systems.

More Famous Security Flaws


57

!  OS/360: Use of data from user space while allowing concurrent input could allow a filename/password pair to have the filename modified after the password had been checked.

!  Trojan Horses: providing ‘free’ and potentially useful programs that perform ‘additional’ functions (like stealing passwords).

!  The Internet Worm: a small bootstrap program ran first on one system, which then uploaded the main worm. The main worm then tried to break passwords which sometimes allowed access to other machines, on which the bootstrap was run, ...

Computer Emergency Readiness Team (CERT)


58

!  This organization was established as a result of the Internet Worm incident. It’s now part of the US Department of Homeland Security.

!  It provides a central place for reporting security problems, which then result in analysis, contact with system vendors, and e-mail to system administrators about potential problems and fixes.

!  Many other web sites now exist to record and report various security-related problems. Most operating system vendors also provide such information.

Generic Security Attacks


59

!  Request resources hoping they contain remnants of their prior contents.

!  Make illegal system calls, or calls with illegal parameters, and observe the effects.

!  Abort login requests part-way through, hoping the password checking will be bypassed.

!  Modify system structures in user space. !  Bribe secretaries, janitors or others to provide information or

physical access to terminals where ‘root’ is logged in. !  Masquerade as a system repairman.

Security Design Principles


60

!  Make the system design public. !  Make the default ‘no access.’ Don’t provide guest

logins. !  Check for current authority to use a resource, not only

once but on each access. !  Provide each process with the minimum rights necessary

to achieve the task at hand. !  The protection mechanism should be simple, uniform,

and built into the lowest layers of the system. !  Make the scheme psychologically acceptable.

User Authentication — Passwords


61

!  Don’t store passwords in unencrypted form - anywhere! !  Choose passwords that are difficult to guess; use mixed

case, digits, and special characters. !  Change passwords frequently. !  Provide challenge-response actions (e.g. what’s your pet’s

name?).

User Authentication — Physical Identity


61.1

!  Require a physical token to be presented prior to access (e.g. a magnetic stripe or “smart” card).

!  Require matching of a physical user characteristic (e.g. retinal, voice or fingerprint scan).

!  Pick a scheme that is acceptable (e.g. no blood samples to be taken for DNA analysis).

Countermeasures


62

!  Log all access attempts, successful and unsuccessful. !  Limit logins to particular terminals, locations, time of

day, etc. !  Use callback for dial-up access (user calls in, then the

system calls back to a specific telephone number for that user).

!  Limit the time allowed for typing a password and the number of failed attempts permitted before automatically disconnecting.

!  Lay traps for intruders by having carefully constructed ‘easy to break’ passwords.

Protection Domains


63

!  A protection domain is a set of (object,rights) pairs, where an object might be a file, a device, or a memory segment, and a right might be read, rewind, or deallocate permission.

!  Protection domains may intersect. !  Each process in the system runs in some domain, but

may switch domains (if permitted by system policies).

Protection Domains: Example


64

Domain 1

File1[R]

File2[RW]

Domain 2

File3[R]

File4[RWX]

File5[RW] Printer1[W]

File6[RWX]

Plotter2[W]

Domain 3

UNIX Protection Domains


65

!  Each UNIX process is identified by a user ID and a group ID (uid and a gid), and whether it is executing in user mode or kernel mode (e.g. processing a system call).

!  Each of these triples (uid,gid,mode) effectively identifies a different protection domain.

!  When executing a file with the SETUID or SETGID bit, the uid or gid associated with a process is temporarily changed to the uid and/or gid of the file during the that file’s execution.

!  This is the technique used to allow execution of privileged actions in a constrained manner (e.g. the passwd command).

Implementing Protection Domains


66

!  There are several common approaches used to implement the sets of (object,rights) pairs for protection domains: ! Access control lists (for objects) !  UNIX rwx-style protection (for objects) ! Capabilities (for processes)

!  Some systems use combinations of these mechanisms (e.g. OS/390).

Access Control Lists (ACLs)


67

!  An access control list is a list of pairs (domain,rights) associated with each object.

!  When a process in domain D attempts to access object O, the system looks through the ACL for O for D, then determines if the rights permit the action being attempted.

Access Control Lists - Example


68

!  Using a UNIX-style domain (uid,gid) as a domain: !  File0: (Connie, *, RWX) !  File1: (Connie, system, RWX) !  File2: (Connie, *, RW-), (Nils, staff, RW-), (Jose, *, RW-) !  File3: (*, student, R--) !  File4: (Mark, *, ---), (*, student, R--)

!  Search, in order, for the first ACL pair for the object that matches the process’ (uid,gid).

Capabilities


69

!  Associate with each process a list of pairs (object,rights) indicating what rights are permitted to object by the process.

!  This can be implemented as an array indexed by integers. Each entry identifies an object type, the process rights, and the unique object (e.g. by device and i-node number for files).

!  Capabilities themselves are objects, and can thus (potentially) be shared with other processes.

Protecting Capabilities


70

!  Capabilities, as part of a user process, must be protected from modification.

!  Several techniques for protecting capabilities include: !  use of a tagged architecture (e.g. Burroughs B5500) in

which the hardware associates a type with each data item (e.g. capabilities).

!  keeping the capabilities in the kernel space. !  keeping capabilities in the user space, but encrypting them

using a key known only to the operating system (as in the Amoeba system).

Generic Capabilities


71

!  Typical capabilities used by systems include: !  copy capability: make a duplicate of the capability for an

object. !  copy object: create a new object with the same capability. !  remove capability: delete an entry in the capability list. !  destroy object: delete object and capability.

Revoking Capabilities


72

!  Revoking access to an object once a capability has been given can be difficult, as this requires identifying all capabilities that reference the object.

!  One approach is to have capabilities point to indirect objects, which themselves point to the object. Deleting the indirect object effectively disables all capabilities.

!  Another approach is to record a large random number in the object and the capability. Owners can change the random number, which is compared with that in the capability.

In Conclusion…


73

!  This is the last module of the course. The material we have covered has provided you with a strong background in operating systems. Of course each topic can be studied further in much greater detail.

!  While there are many different operating systems, each has basically the same set of goals, and will provide basically the same services we have studied. With the knowledge you have gained in this course, understanding the structure of any new operating system should be easy.

computer science 4500 operating...

Documents