1. Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University Summers_wayne@colstate.edu http://csc.colstate.edu/summers

2. 2 Requirements and Policy  Access to a role account is based on user, location, and time of request.  The settings of the role account’s environment shall replace the corresponding settings of the user’s environment, but the remainder of the user’s environment shall be preserved.  Only root can alter the access control information for access to a role account.  The mechanism shall allow both restricted access and unrestricted access to a role account. For unrestricted access, the user shall have access to a standard command interpreter. For restricted access, the user shall be able to execute only a specified set of commands.  Access to the files, directories, and objects owned by any account administered by use of this mechanism shall be restricted to those authorized to use the role account, to users trusted to install system programs, and to root.

3. 3 Threats  An unauthorized user may obtain access to a role account as though she were an authorized user.  An authorized user may use a nonsecure channel to obtain access to a role account, thereby revealing her authentication information to unauthorized individuals.  An unauthorized user may alter the access control information to grant access to the role account.  An authorized user may execute a Trojan horse ( or other form of malicious logic), giving an unauthorized user access to the role account.  An authorized user may obtain access to a role account and perform unauthorized commands.  An authorized user may execute a command that performs functions that the user is not authorized to perform.  An authorized user may change the restrictions on the user/s ability to obtain access to the account.

4. 4 Design  Framework –User Interface –High-Level Design Obtain role account, command, user, location, time of day. Check that user is allowed to access role account Obtain user/group information for role account Overlay child process with command interpreter that spawns the named command Overlay child process with command interpreter –Requirement 29.3.1: combines requirements 29.2.4 with 29.2.1

5. 5 Design  Access to Roles and Commands –Interfaces Minimize amount of information passed to access checking module Boolean accessok(role rname, command cmd); –Internals Obtain user ID, Time, entry point, remote host Obtain handle to the access control information Iterate through records until data matched –Storage of the Access Control Data

6. 6 Refinement and Implementation  1rst Level Refinement: Pseudo-code  2 nd Level Refinement: map to a language  Code Functions –Obtaining location –The access control record structure –Error handling in the Reading and Matching Routines

7. 7 Common Security-Related Programming Problems  Improper Choice of Initial Protection Domain –Process Privileges Structure the process so that all sections requiring extra privileges are modules. The modules should be as small as possible and should perform only those tasks that require those privileges Check that process privileges are set properly –Access Control File Permissions Protect program that is executed to create the process, and all associated control files, from unauthorized use/modification. [any modification must be detected] Ensure that any assumptions in the program are validated.

8. 8 Common Security-Related Programming Problems  Memory Protection Ensure that program does not share objects in memory with other programs & programs cannot access memory of a privileged process Configure memory to enforce principle of least privilege.  Trust in the System Identify all system components on which the program depends. Check for errors whenever possible.

9. 9 Common Security-Related Programming Problems  Improper Isolation of Implementation Detail Check error status of every function –Resource Exhaustion and User Identifiers –Validating Access Control Entries –Restricting Protection Domain of Role Process

10. 10 Common Security-Related Programming Problems  Improper Change –Memory Synchronize process interaction with other processes Asynchronous exception handlers should not alter any variables except those that are local to module. Separate trusted data from data from untrusted sources –Changes in File Contents Do not use components that may change between the time the program is created and time it is run. –Race Conditions in File Access Time-of-check-to-time of use problem

11. 11 Common Security-Related Programming Problems  Improper Naming Unique objects require unique names Process must ensure that the context in which an object is named identifies the correct object  Improper Deallocation / Deletion Erase sensitive object when the process finishes using, then deallocate or delete  Improper Validation –Bounds checking Ensure array references access existing elements of array –Type Checking Check types of functions and parameters Ensure compiler reports inconsistencies in types

12. 12 Common Security-Related Programming Problems  Improper Validation –Error Checking Check function and procedure executions for errors –Checking for Valid, not Invalid, Data Check that variable’s values are valid If trade-off between security and other factors results in a mechanism/procedure that can weaken security, document reasons for decision, possible effects, and situations in which the compromise method should be used.

13. 13 Common Security-Related Programming Problems  Improper Validation –Checking Input Check all user input for both form and content –Designing for Validation Create data structures and functions that can be validated  Improper Indivisibility If two operations must be performed sequentially without an intervening operation, use mechanism to ensure that the two cannot be divided

14. 14 Common Security-Related Programming Problems  Improper Sequencing –Describe legal sequences of operations on a resource/object.  Improper Choice of Operand / Operation Use software engineering & assurance techniques to ensure that operations and operands are appropriate

15. 15 Testing, Maintenance, and Operation  Testing the Module –List all interfaces –Test normal data –Test boundary data –Test exceptions (interrupts & traps) –Test random data  Testing Composed Modules –Test error handling  Testing the Program (use non-tester personnel)

16. 16 Distribution  Who can use the program?  How can the integrity of the master copy be protected?  How can the availability of the program be ensured?