UNIT -2

Confidentiality Policies
• Confidentiality Policies emphasize the protection of confidentiality. Confidentiality
policy also called information flow policy which prevents unauthorized disclosure of
information.
• Example: Privacy Act requires that certain personal data be kept confidential. E.g.,
income tax return info only available to IT department and legal authority with court
order. It limits the distribution of documents/info.
• Confinement ensure that misbehaving applications cannot harm rest of system. It
can be implemented at many levels:
• Hardware level: At this level run application on isolated hardware (air gap).
• Virtual machines level: At this level run isolate OS’s on a single machine.
• Process level: At this level implement System Call Interposition or run isolate process
on single machines.
• Threads level: At this level implement Software Fault Isolation (SFI).
• DAC is based on user identity and ownership.
– Programs run by a user inherits all privileges granted to the user.
– Program is free to change access to the user’s objects
• It supports only two major categories of users:
• Completely trusted admins.
• Completely untrusted ordinary users.
• DAC is only based on user’s identity and ownership, ignoring security relevant info
such as
– User’s role
– Function of the program
– Trustworthiness of the program and this is the main drawback of DAC mechanism.
To overcome this drawback, we can have MAC mechanism.
• Application level: e.g. browser-based confinement. We can used Discretionary
Access Control(DAC) to implement browser based confinement.
• MAC is a mechanism where system controls access to an object and a user cannot
alter that access.
• It is defined by three major properties:
 – Administratively-defined security policy
– Control over all subjects (process) and objects (files, sockets, network interfaces)
– Decisions based on all security-relevant info
• MAC access decisions are based on labels that contains security-relevant info.
• DAC is a mechanism where a user can set access control to allow or deny access to
an object. It is also called Identity-based access control (IBAC). It is a traditional
access control techniques implemented by traditional operating system such as Unix.
Detour Unix user IDs Process IDs and privileges
• A Detour is a few words about Unix User IDs and IDs associated with Unix Processes.
• A subject is a program (application) executing on behalf of some principal(s).
• 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:
• File, Directory (or Folder) and Memory Segment but, subjects can also be objects,
with operations:
• kill
• Suspend
• Resume
• Each user account has a unique UID. The UID 0 means the super user (system admin)
• A user account belongs to multiple groups
• Subjects are processes
– associated with uid/gid pairs, e.g., (euid, egid), (ruid, rgid), (suid, sgid)
• Objects are files
• Users (Real World User) and principals (Unit of Access Control and Authorization)
• The system authenticates the human user to a particular principal.
• There should be a one-to-many mapping from users to principals
• a user may have many principals, but
• each principal is associated with an unique user
• This ensures accountability of a user's actions
• Organization of data
• Almost all objects are modelled as files
– Files are arranged in a hierarchy
– Files exist in directories
– Directories are also one kind of files
• Each object has
– owner
– group
– 12 permission bits
• rwx for owner, rwx for group, and rwx for others
• suid, sgid, sticky
• Other Issues On Objects in UNIX
• Accesses other than read/write/execute
– Who can change the permission bits?
• The owner can
– Who can change the owner?
• Only the super user
• Rights not related to a file
– Affecting another process
– Operations such as shutting down the system, mounting a new file system,
listening on a low port
• traditionally reserved for the root user
• Access rights are specified for users (accounts)
• Accesses are performed by processes (subjects)
• The OS needs to know on which users’ behalf a process is executing
• Each process has three user IDs
– real user ID (ruid) owner of the process
– effective user ID (euid) used in most access
– saved user ID (suid)
• and three group IDs
– real group ID , effective group ID and saved group ID
 • When a process is created by fork it inherits all three users IDs from its parent
process
• When a process executes a file by exec it keeps its three user IDs unless the set-
user-ID bit of the file is set, in which case the effective uid and saved uid are assigned
the user ID of the owner of the file.
• A process may change the user ids via system calls.
• Some operations are not modelled as files and require user id = 0
– halting the system and bind/listen on “privileged ports” (TCP/UDP ports below
1024)
– non-root users need these privileges
• File level access control is not fine-grained enough
• System integrity requires more than controlling who can write, but also how it is
written
System call interposition
• Observation: to damage host system (e.g. persistent changes) app must make
system calls:
– To delete/overwrite files: unlink, open, write
– To do network attacks: socket, bind, connect, send
• Idea: monitor app’s system calls and block unauthorized calls
• Implementation options:
– Completely kernel space (e.g. GSWTK) -- security extension architecture.
– Completely user space (e.g. program shepherding)
– Hybrid (e.g. Systrace)
• Initial implementation (Janus)- Linux ptrace: process tracing
• process calls: ptrace (... , pid_t pid , ...) and wakes up when pid makes sys call.
• If app forks, monitor must also fork
– forked monitor monitors forked app
• If monitor crashes, app must be killed
• Monitor must maintain all OS state associated with app
– current-working-dir (CWD), UID, EUID, GID
– When app does “cd path” monitor must update its CWD
 • otherwise: relative path requests interpreted incorrectly
• Ptrace is not well suited for this application:
– Trace all system calls or none
• inefficient: no need to trace “close” system call
– Monitor cannot abort sys-call without killing app
• Security problems: race conditions
– Example: symlink: me � mydata.dat
• proc 1: open(“me”)
• monitor checks and authorizes
• proc 2: me � /etc/passwd
• OS executes open(“me”)
• systrace only forwards monitored sys-calls to monitor (efficiency)
• systrace resolves sym-links and replaces sys-call path arguments by full path to
target. When app calls execve, monitor loads new policy file.
• Systrace executes the application without privileges and only elevates them to the
desired level when
• required.
• native-socket: sockdom eq "AF_INET" and socktype eq "SOCK_RAW" then permit
as root
• native-bind: sockaddr eq "inet-[0.0.0.0]:22" then permit as root
• native-fsread: filename eq "/dev/kmem" then permit as :kmem
• A simple policy for the ls binary. If ls attempts to list files in /etc, Systrace disallows
the access and /etc does not seem to exist. Listing the contents of /tmp works
normally, but trying to ls /var generates a warning.
• Previous designs use filtering:
• Filter examines sys-calls and decides whether to block
• Difficulty with syncing state between app and monitor (CWD, UID, ..)
– Incorrect syncing results in security vulnerabilities (e.g. disallowed file opened)
• Delegation architecture: Monitored app disallowed from making monitored sys calls
– Minimal kernel change (... but app can call close() itself )
• Sys-call delegated to an agent that decides if call is allowed
 – Can be done without changing app
• (requires an emulation layer in monitored process)
• Incorrect state syncing will not result in policy violation
VM based isolation
• Single HW platform used for both classified and unclassified data.
• VMs in the 1960’s:
– Few computers, lots of users
– VMs allow many users to shares a single computer
• VMs 1970’s – 2000: non-existent
• VMs since 2000:
– Too many computers, too few users
• Print server, Mail server, Web server, File server, Database,...
– Wasteful to run each service on different hardware
– More generally: VMs heavily used in cloud computing
• VMM Security assumption:
– Malware can infect guest OS and guest apps
– But malware cannot escape from the infected VM
• Cannot infect host OS
• Cannot infect other VMs on the same hardware
• Requires that VMM protect itself and is not buggy
– VMM is much simpler than full OS
• ... but device drivers run in Host OS
• Problem: covert channels
• Covert channel: unintended communication channel
• between isolated components
– Can be used to leak classified data from secure
• component to public component
Software fault isolation
• Goal: confine apps running in same address space
 – Codec code should not interfere with media player
– Device drivers should not corrupt kernel
• Simple solution: runs apps in separate address spaces
– Problem: slow if apps communicate frequently
• requires context switch per message
• SFI approach: Partition process memory into segments
• Locate unsafe instructions: jmp, load, store
– At compile time, add guards before unsafe instructions
– When loading code, ensure all guards are present
• Shared memory: use virtual memory hardware
– map same physical page to two segments in addr space
• Performance: Usually good: mpeg_play, 4% slowdown
• Limitations of SFI: harder to implement on x86 :
– variable length instructions: unclear where to put guards
– few registers: can’t dedicate three to SFI
– many instructions affect memory: more guards needed

Root kits
• Rootkits: Collection of attacker tools installed after an intruder has gained access
– Log cleaners
– File/process/user hiding tools
– Network sniffers
– Backdoor programs
Goals of Rootkits
• Remove evidence of original attack and activity that led to rootkit installation.
• Hide future attacker activity (files, network connections, processes) and prevent it
from being logged.
• Enable future access to system by attacker.
• Install tools to widen scope of penetration.
• Secure system so other attackers can’t take control of system from original attacker.
Rootkit Types
• User-mode Rootkits
– Binary Rootkits replace user programs.
• Trojans: ls, netstat, ps
• Trojan backdoors: login, sshd.
– Library Rootkits replace system libraries.
• Intercept lib calls to hide activities and add backdoors.
• Kernel Rootkits
– Modify system calls/structures that all user-mode programs rely on to list users,
processes, and sockets.
– Add backdoors to kernel itself.
Binary Rootkits
Install trojan-horse versions of common system commands, such as ls, netstat, and ps to
hide attacker activities..
• Install programs to edit attacker activity from log and accounting files.
• Install trojan-horse variants of common programs like login, passwd, and sshd to
allow attacker continued access to system.
• Install network sniffers.
Library Rootkits
t0rn rootkit uses special system library libproc.a to intercept
• process information requested by user utilities.
• Modify libc
– Intercept system call data returning from kernel, stripping out
• evidence of attacker activities.
– Alternately, ensure that rootkit library providing system calls is called
• instead of libc by placing it in /etc/ld.so.preload.
Kernel Rootkits
• Kernel runs in supervisor processor mode
– Complete control over machine.
• Rootkits modify kernel system calls
 – execve modified to run Trojan horse binary for some programs,while other system
calls used by integrity checkers read original binary file.
– setuid modified to give root to a certain user.
• Advantage—Stealth
– Runtime integrity checkers cannot see rootkit changes.
– All programs impacted by kernel Trojan horse.
– Open backdoors/sniff network without running processes.
Intrusion detection system
• Intrusion: Attempting to break into or misuse your system.
• Intruders may be from outside the network or legitimate
• users of the network.
• Intrusion can be a physical, system or remote intrusion.
Different ways to intrude
• Buffer overflows
• Unexpected combinations
• Unhandled input
• Race conditions
Signature Based:
• Intrusion Detection Systems look for attack signatures, which are specific patterns
that usually indicate malicious or suspicious intent.
Anomaly Detection Based:
• Machine learning techniques used to characterize normal behaviour from
anomalous behaviour.
Different ways of classifying an IDS
• IDS based on
– anomaly detection
– signature based misuse
– host based
– network based
Anomaly based IDS
This IDS models the normal usage of the network as a noise characterization.
• Anything distinct from the noise is assumed to be an intrusion activity.
– E.g flooding a host with lots of packet.
• The primary strength is its ability to recognize novel attacks.
• Drawbacks of Anomaly detection IDS
• Assumes that intrusions will be accompanied by manifestations that are sufficiently
unusual so as to permit detection.
• These generate many false alarms and hence compromise the
• effectiveness of the IDS.
Signature based IDS
This IDS possess an attacked description that can be matched to sensed attack
manifestations.
• The question of what information is relevant to an IDS
• depends upon what it is trying to detect.
– E.g DNS, FTP etc.
• ID system is programmed to interpret a certain series of packets, or a certain piece
of data contained in those packets,as an attack. For example, an IDS that watches
web servers might be programmed to look for the string “phf” as an indicator of a
CGI program attack.
• Most signature analysis systems are based off of simple patter matching algorithms.
In most cases, the IDS simply looks for a sub string within stream of data carried by
network packets. When it finds this sub string (for example, the ``phf'' in ``GET /cgi-
bin/phf?''), it identifies those network packets as vehicles of an attack.
• Drawbacks of Signature based IDS
• They are unable to detect novel attacks.
• Suffer from false alarms
• Have to be programmed again for every new pattern to be detected.
Host/Applications based IDS
The host operating system or the application logs in the audit information. These audit
information includes events like the use of identification and authentication mechanisms
(logins etc.) , file opens and program executions, admin activities etc. This audit is then
analyzed to detect trails of intrusion.
Drawbacks of the host based IDS
• The kind of information needed to be logged in is a matter of
experience.
• Unselective logging of messages may greatly increase the audit and analysis burdens.
• Selective logging runs the risk that attack manifestations could be missed.
Strengths of the host based IDS
Attack verification
• System specific activity
• Encrypted and switch environments
• Monitoring key components
• Near Real-Time detection and response.
• No additional hardware
Stack based IDS
They are integrated closely with the TCP/IP stack, allowing packets to be watched as they traverse
their way up the OSI layers. This allows the IDS to pull the packets from the stack before the OS or
the application have a chance to process the packets.

Network based IDS

This IDS looks for attack signatures in network traffic via a promiscuous interface. A filter is
usually applied to determine which traffic will be discarded or passed on to an attack
recognition module. This helps to filter out known un-malicious traffic.
Strengths of Network based IDS
• Cost of ownership reduced
• Packet analysis
• Real time detection and response
• Malicious intent detection
• Operating system independence
Error 404 digital hacking in India part 2 chase
• With airports across India trying to push for Aadhaar-enabled check-ins for improved
security and managing passenger traffic, questions are being raised about the
possible misuse of personal data, in the absence of stricter data privacy regulations.
• The Aadhaar database is encrypted and kept securely and not used or shared with
anyone. This is a very secure preservation of data.
• But that’s not the only place because when we do transaction we provide fingerprint
to the public biometric reader for authentication purpose and optical sensor of
biometric reader capture a photography of our fingerprint and transfer that to a
computer via a USD cable.
• The host computer then converts the fingerprint into a template which is then
converted into a PID or personal identity block.
• The personal ID block sent to the UIDAI through a series of intermediary gateway
servers.
• The UIDAI server respond with either a successful or failed authentication. However,
there are several vulnerabilities:
(1) Host computer can store the users biometric which can then be used without the
individual’s consent.
(2) PID block is not encrypted so it is vulnerable to interception by hackers.
(3) Host computer is also connected to public internet servers and hence is
vulnerable to viruses and malware that can steal the PID block.