Confinement Principle:

The confinement principle deals with preventing a server from disclosing the information that
the user of the service considers confidential.
The confinement ensures that the webserver should allow accessing certain services to
authorized users only.
When a client makes data request to the server then the server checks whether the client
authorized to access the data/service.
If the client is authorized then the server allows the client to access certain services,
otherwise, the server restricts the client to take unallowed action.

Let’s assume a client-server situation: The client makes data request to the server then first of
all the server identifies whether the client is authorized to access the data. If the client is
authorized the server uses the data and performs some function and sends back the desired
data to the client.
In confinement principle, access control affects the server in two ways:
The goal of the service provider: The server must ensure that the resources that are being
accessed on the behalf of the client include only those resources that the client is authorized
for.
The goal of the service user: The server must ensure the privacy of the service user. The
server should never disclose the client’s data without the permission of the client. The client
data could be seen by only those entities to whom the client is allowed to see.

Detour Unix user ids process ids and privileges:

Q. Describe detour used in Unix user ids and process ids.
1. Detour is defined as few words about Unix user IDs and IDs associated with Unix
processes.
2. Every user in UNIX like operating system is identified by different integer number, this
unique number is called as UserID.
3. There are three types of UID defined for a process, which can be dynamically changed as
per the privilege of task.
4. The three different types of UIDS defined are :
À). Real UserID: It is account of owner of this process. It defines which files that this process
has access to.
B). Effective UserID: It is normally same as real UserID, but sometimes it is changed to
enable a non-privileged user to access files that can only be accessed by root.
C). Saved UserID: It is used when a process is running with elevated privileges (generally
root) needs to do some under-privileged work; this can be achieved by temporarily switching
to non-privileged account.
5. A subject is a program (application) executing on behalf of some principal(s).
6. A principal may at any time be idle, or have one or more subjects executing on its behalf.
An object is anything on which a subject can perform operations (mediated by rights) usually
objects are passive, for example:
a. File
b. Directory (or folder)
c. Memory segment.
7. Each user account has a unique UID. The UID 0 means the super user (System admin). A
user account belongs to multiple groups. Subject is processes, associated with uid/gid pairs.
System Call Interposition:
In computing, a system call is the programmatic way in which a computer program requests a
service from the kernel of the operating system it is executed on. A system call is a way for
programs to interact with the operating system.
A computer program makes a system call when it makes a request to the operating system’s
kernel. System call provides the services of the operating system to the user programs via
Application Program Interface(API).
It provides an interface between a process and operating system to allow user-level processes
to request services of the operating system. System calls are the only entry points into the
kernel system. All programs needing resources must use system calls.
Services Provided by System Calls:
1. Process creation and management
2. Main memory management
3. File Access, Directory and File system management
4. Device handling(I/O)
5. Protection
6. Networking, etc.
Types of System Calls:
There are 5 different categories of system calls –
1. Process control: end, abort, create, terminate, allocate and free memory.
2. File management: create, open, close, delete, read file etc.
3. Device management
4. Information maintenance
5. Communication

Examples of Windows and Unix System Calls –

System call interposition is a powerful approach to restrict the power of a program by
intercepting its system call
Sandboxing techniques based on system call interposition have been developed in the past.
System calls allow virtually all of a program's interactions with the network, file system, and
other sensitive system resources.
System call interposition is a powerful approach to restrict the power of a program
There exists a significant body of related work in the domain of system call interposition.
Implementing system call interposition tools securely can be quite subtle
Garfunkel studies the common mistakes and pitfalls, and uses the system call interposition
technique to enforce security policies in the Ostia tool.
By restricting system calls, we could also limit the impact that an adversary can make if a
container is compromised.
System call interposition is a powerful approach to restrict the power of a program by
intercepting its system calls (Garfinkel et al. 2003).

Sandboxing techniques based on system call interposition have been developed in the past.
System calls allow virtually all of a program's interactions with the network, file system and
other sensitive system resources. System call interposition is a powerful approach to restrict
the power of a program
There exists a significant body of related work in the domain of system call interposition.
Implementing system call interposition tools securely can be quite subtle.

Software-based Fault Isolation

We have been discussing protection measures that a single operating system can provide. One
way to think of this is to view the operating system as a padded cell in which programs
operate; we have been discussing the nature of the padding. Another way to get programs to
behave in a manner consistent with a given security policy is by "brainwashing." That is,
modify the programs so that they behave only in safe ways. This is embodied by a recent
approach to security known as software-based fault isolation (SFI).
So far, the environment has been responsible for policy enforcement, where the environment
is either the OS/kernel or the hardware. Hardware methods include addressing mechanisms
(e.g. virtual memory); OS methods include having two modes (where the supervisor mode
has access to everything). The new approach we discuss today is to construct a piece of
software that transforms a given program p into a program p', where p' is guaranteed to
satisfy a security policy of interest.

This SFI SW transformation could be any number of things. It could be a piece of the
compiler or of the loader. It could also involve a separate pass over machine language code
before execution commences. The point is that we are modifying the program before it is
executed. (One easy realization of SFI SW is to always output a program that does nothing.
However, there are likely to be properties of the original program that we are interested in
preserving, and these properties might not be satisfied by a program that does nothing.)

When would the SFI approach be useful (as opposed to the other approaches we have been
discussing this semester)?

 If we are trying to run programs on a machine that lacks suitable protection hardware,
then with this method we can achieve the functionality that the hardware doesn't
support.
 Another application is when hardware doesn't support the security policy of interest.
This is likely to become increasingly important, especially in situations where security
policies relate to higher-level abstractions (e.g. paragraphs in a document being
assigned security ratings). If the hardware or the OS software doesn't know about a
particular abstraction, we can add a program as described above to handle it.
 The original motivation for this approach was performance. We can use SFI to
achieve memory protection at a low cost. Most operating systems/HW provide
security by protecting disjoint address spaces. However, programs operating in these
isolated address spaces need to communicate with each other. An inter-process
communication (IPC) provided by the operating system is invariably 10-100 times as
costly as a procedure call. An IPC needs to trap, copy arguments, save/restore
arguments, change the address space and then repeat all of the above on the way out.
We would like to avoid this costly mechanism and can replace it with SFI.
 Another use might be for programs that support plug-ins. We would like to protect the
main program (e.g. a browser) from buggy plug-ins. This is a form of "sub-address
 space" protection, since the browser and the plug-in execute in the same address
space.
 Finally, this approach is useful for programs comprising many "objects." Such
programs would profit from having sub-address space level protection. If one object
"goes bad," it would be nice if that behavior didn't trash everything else. However, an
IPC-like operation that would accompany operating system address space protection
is likely to be much too expensive for use with every method invocation.

IDS:
An Intrusion Detection System (IDS) is a monitoring system that detects suspicious activities and
generates alerts when they are detected. Based upon these alerts, a security operations center
(SOC) analyst or incident responder can investigate the issue and take the appropriate actions to
remediate the threat.

Intrusion detection systems are designed to be deployed in different environments. And like
many cybersecurity solutions, an IDS can either be host-based or network-based.

 Host-Based IDS (HIDS): A host-based IDS is deployed on a particular endpoint and

designed to protect it against internal and external threats. Such an IDS may have the
ability to monitor network traffic to and from the machine, observe running processes,
and inspect the system’s logs. A host-based IDS’s visibility is limited to its host
machine, decreasing the available context for decision-making, but has deep visibility
into the host computer’s internals.
 Network-Based IDS (NIDS): A network-based IDS solution is designed to monitor
an entire protected network. It has visibility into all traffic flowing through the
network and makes determinations based upon packet metadata and contents. This
wider viewpoint provides more context and the ability to detect widespread threats;
however, these systems lack visibility into the internals of the endpoints that they
protect.

Detection Method of IDS Deployment

Beyond their deployment location, IDS solutions also differ in how they identify potential
intrusions:

 Signature Detection: Signature-based IDS solutions use fingerprints of known

threats to identify them. Once malware or other malicious content has been identified,
a signature is generated and added to the list used by the IDS solution to test incoming
content. This enables an IDS to achieve a high threat detection rate with no false
positives because all alerts are generated based upon detection of known-malicious
content. However, a signature-based IDS is limited to detecting known threats and is
blind to zero-day vulnerabilities.
 Anomaly Detection: Anomaly-based IDS solutions build a model of the “normal”
behavior of the protected system. All future behavior is compared to this model, and
any anomalies are labeled as potential threats and generate alerts. While this approach
can detect novel or zero-day threats, the difficulty of building an accurate model of
 “normal” behavior means that these systems must balance false positives (incorrect
alerts) with false negatives (missed detections).
 Hybrid Detection: A hybrid IDS uses both signature-based and anomaly-based
detection. This enables it to detect more potential attacks with a lower error rate than
using either system in isolation.