MODULE 5
PROGRAM SECURITY
Program Security: Introduction, Requirements and Policy,
Design, Refinement and Implementations (Text 3: Chapter
19: Section 1, 2, 3, 4)
Prepared By:
Dr. Shruthi M
Associate Professor
Department of Electronics and Communication
1
Q1. Explain the requirements of program security?
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.
Q2. Explain the threats in program security?
The threats against this mechanism fall into distinct classes.
Group 1: Unauthorized Users Accessing Role Accounts There are four
threats that involve attackers trying to acquire access to role accounts
using this mechanism.
Threat 2.1. An unauthorized user may obtain access to a role account as though
she were an authorized user.
Threat 2.2. An authorized user may use a nonsecure channel to obtain access to
a role account, thereby revealing her authentication information to
unauthorized individuals.
Threat 2.3. An unauthorized user may alter the access control information to
grant access to the role account.
Threat 2.4. An authorized user may execute a Trojan horse (or other form of
malicious logic),3 giving an unauthorized user access to the role account.
Group 2: Authorized Users Accessing Role Accounts Because access is
allowed here, the threats relate to an authorized user changing access
permissions or executing unauthorized commands.
Threat 2.5. An authorized user may obtain access to a role account and per
form unauthorized commands.
2
Threat 2.6. An authorized user may execute a command that performs func
tions that the user is not authorized to perform.
Threat 26.2.7. An authorized user may change the restrictions on the user’s
ability to obtain access to the account.
Q3. Explain the basic algorithm of High level design in programs
security?
The basic algorithm is as follows.
1. Obtain the role account, command, user, location, and time of day. If the
command is omitted, the user requests unrestricted access to the role account.
2. Check that the user is allowed to access the role account a. at the specified
location; b. at the specified time; and c. for the specified command (or without
restriction). If the user is not, log the attempt and quit.
3. Obtain the user and group information for the role account. Change the
privileges of the process to those of the role account.
4. If the user has requested that a specific command be run, overlay the child
process with a command interpreter that spawns the named command.
5. If the user has requested unrestricted access, overlay the child process with a
command interpreter.
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. The level of access (restricted or
unrestricted) shall depend on the user, the role, the time, and the location.
Thus, the design phase feeds back into the requirements phase, here clarifying
the meaning of the requirements. It is left as an exercise for the reader to verify
that the new form of this requirement counters the appropriate threats
Q4. Explain the refinement levels in program security?
1. First-Level Refinement
The module is first written in pseudocode, not a specific programming
language.
3
A block-structured language (like C) and a UNIX-like system
(Linux/FreeBSD) are assumed.
The interface remains unchanged, matching the original design.
Variable stat is initialized to false to follow fail-safe defaults (deny access
by default).
User ID, time, and system entry point are collected, then the access control
file is opened.
The routine checks each record in the file:
If any record grants access, return true immediately.
If no record grants access, return false.
Since the file only contains allow rules, absence of a match means access is
denied.
Thus, the pseudocode correctly matches the design and requirements
2. Second level refinement
C language is chosen because it is widely available and well suited for
UNIX-like systems such as Linux.
Roles are represented as normal user accounts; internally, identity is
handled using uid_t (integer form).
Using uid_t is preferred because:
The kernel represents identities only as uid_t.
Access control file entries (names or numbers) can be converted and
validated.
4
Design decision: represent all user and role IDs internally as integers;
this does not affect earlier design choices.
A command is represented as an array of strings (char *cmd[]),
where the first element is the program name.
Final interface:
int accessok (uid_t rname, char *cmd[])
The real user ID (not effective UID) identifies the user:
userid = getuid();
Time of day is obtained in seconds for simplicity:
timeday = time(NULL);
Location is obtained via an encapsulated function for portability:
entry = getlocation();
The access control file is opened with error checking and logging.
Records are read one by one and checked:
If any record grants access → return true.
If all records are exhausted → return false.
The file is closed and the final status is returned.
Q5. Explain the three functions of user security?
Three functions remain: the function for obtaining location, the function for
getting an access control record, and the function for checking the access
control record against the information of the current process. Each raises
security issues.
1. Obtaining the location
UNIX and Linux systems write the user’s account name, the name of the
terminal on which the login takes place, the time of login, and the name of
the remote host (if any) to the utmp file. Any process may read this file. As
each new process runs, it may have an associated terminal. To determine
the utmp record associated with the process, a routine may obtain the
associated terminal name, open the utmp file, and scan through the record
to find the one with the corresponding terminal name.
This approach, although clumsy, works on most UNIX and Linux systems.
It suffers from two problems related to security.
1. If any process can alter the utmp file, its contents cannot be trusted.
Several security holes have occurred because any process could alter the
utmp file.
2. A process may have no associated terminal. Such a detached process
must be mapped into the corresponding utmp record through other means.
5
However, if the utmp record contains only the information described
above, this is not possible because the user may be logged into multiple
terminals.
The issue does not arise if the process has an associated terminal, because
only one user at a time may be logged into a terminal.
The outline of this routine is
2. The Access Control Record
The format of the records in the access control file affects both the
reading of the file and the comparison with the process information, so
we design it here. Our approach is to consider the match routine first.
Four items must be checked: the user name, the location, the time, and the
command. Consider these items separately.
User names are handled internally as integers (uid_t), but stored in the
access control record as strings.
The match routine converts user names to integers only when needed,
using lazy evaluation (stop converting once a match is found).
The same lazy parsing strategy is used for location and command
fields.
6
The record-reading routine simply loads each record as a sequence of
strings; interpretation is done later by the match routine.
Time handling differs:
o Time entries are treated as ranges, not exact matches.
o Example: “May 30” means from May 30 00:00 to May 31 00:00.
o Internally, this corresponds to a start and end timestamp.
If access is allowed at an exact second, the time range has identical start
and end values.
The match routine checks whether the current system time falls within
the specified range.
This yields the following structure
3. Error Handling in the Reading and Matching Routines
Syntax errors in the access control file (e.g., wrong time format or
corrupted record) must not be ignored.
Ignoring errors violates security principles and may wrongly deny
legitimate access.
The program must detect and report errors.
Errors should be logged, not just displayed, so the system administrator is
informed even if users do not report them.
Whether detailed error messages are shown to users is debatable; at
minimum, users should know that access is denied.
Logged errors must include file name and line/record number to help
locate the problem.
Therefore, record counts, line numbers, and file name must be shared
between routines.
For modularity, record-reading and matching routines should be placed in
a submodule under the access-checking routine.
This design prevents unauthorized external access to the access control
file logic.
7
Design concept refer text book