chapter 5b n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 5b PowerPoint Presentation
Download Presentation
Chapter 5b

Loading in 2 Seconds...

play fullscreen
1 / 70

Chapter 5b - PowerPoint PPT Presentation


  • 141 Views
  • Uploaded on

Chapter 5b. Modern Operating Systems Security Linux and Windows (Vista) Stallings chapters 23,24. Computer Security: Principles and Practice. Chapter 23 – Linux Security. First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown. Linux Security.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 5b' - nadda


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 5b
Chapter 5b

Modern Operating Systems

Security

Linux and Windows (Vista)

Stallings chapters 23,24

computer security principles and practice

Computer Security: Principles and Practice

Chapter 23 – Linux Security

First Edition

by William Stallings and Lawrie Brown

Lecture slides by Lawrie Brown

linux security
Linux Security
  • Linux has evolved into one of the most popular and versatile operating systems
  • many features mean broad attack surface
  • can create highly secure Linux systems
  • will review:
    • Discretionary Access Controls
    • typical vulnerabilities and exploits in Linux
    • best practices for mitigating those threats
    • new improvements to Linux security model
linux security model
Linux Security Model
  • Linux’s traditional security model is:
    • people or proceses with “root” privileges can do anything
    • other accounts can do much less
  • hence attacker’s want to get root privileges
  • can run robust, secure Linux systems
  • crux of problem is use of Discretionary Access Controls (DAC)
file system security
File System Security
  • in Linux everything as a file
    • e.g. memory, device-drivers, named pipes, and other system resources
    • hence why filesystem security is so important
  • I/O to devices is via a “special” file
    • e.g. /dev/cdrom
  • have other special files like named pipes
    • a conduit between processes / programs
users and groups
Users and Groups
  • a user-account (user)
    • represents someone capable of using files
    • associated both with humans and processes
  • a group-account (group)
    • is a list of user-accounts
    • users have a main group
    • may also belong to other groups
  • users & groups are not files
users and groups1
Users and Groups
  • user's details are kept in /etc/password

maestro:x:200:100:Maestro Edward Hizzersands:/home/maestro:/bin/bash

  • additional group details in /etc/group

conductors:x:100:

pianists:x:102:maestro,volodya

  • use useradd, usermod, userdel to alter
file permissions
File Permissions
  • files have two owners: a user & a group
  • each with its own set of permissions
  • with a third set of permissions for other
  • permissions are to read/write/execute in order user/group/other, cf.

-rw-rw-r-- 1 maestro user 35414 Mar 25 01:38 baton.txt

  • set using chmod command
directory permissions
Directory Permissions
  • read = list contents
  • write = create or delete files in directory
  • execute = use anything in or change working directory to this directory
  • e.g.

$ chmod g+rx extreme_casseroles

$ ls -l extreme_casseroles

drwxr-x--- 8 biff drummers 288 Mar 25 01:38 extreme_casseroles

sticky bit
Sticky Bit
  • originally used to lock file in memory
  • now used on directories to limit delete
    • if set must own file or dir to delete
    • other users cannot delete even if have write
  • set using chmod command with +t flag, e.g.

chmod +t extreme_casseroles

  • directory listing includes t or T flag

drwxrwx--T 8 biff drummers 288 Mar 25 01:38 extreme_casseroles

  • only apply to specific directory not child dirs
setuid and setgid
SetUID and SetGID
  • setuid bit means program "runs as" owner
    • no matter who executes it
  • setgid bit means run as a member of the group which owns it
    • again regardless of who executes it
  • "run as" = "run with same privileges as”
  • are very dangerous if set on file owned by root or other privileged account or group
    • only used on executable files, not shell scripts
setgid and directories
SetGID and Directories
  • setuid has no effect on directories
  • setgid does and causes any file created in a directory to inherit the directory's group
  • useful if users belong to other groups and routinely create files to be shared with other members of those groups
    • instead of manually changing its group
kernel vs user space
Kernel vs User Space
  • Kernel space
    • refers to memory used by the Linux kernel and its loadable modules (e.g., device drivers)
  • User space
    • refers to memory used by all other processes
  • since kernel enforces Linux DAC and security critical to isolate kernel from user
    • so kernel space never swapped to disk
    • only root may load and unload kernel modules
setuid root vulnerabilities
setuid root Vulnerabilities
  • a setuid root program runs as root
    • no matter who executes it
  • used to provide unprivileged users with access to privileged resources (e.g. change passwd)
  • must be very carefully programmed
  • if can be exploited due to a software bug
    • may allow otherwise-unprivileged users to use it to wield unauthorized root privileges
  • distributions now minimize setuid-root programs
  • system attackers still scan for them!
web vulnerabilities
Web Vulnerabilities
  • a very broad category of vulnerabilities
    • because of ubiquity of world wide web have big and visible attack surfaces
  • when written in scripting languages
    • not as prone to classic buffer overflows
    • can suffer from poor input-handling
  • few “enabled-by-default” web applications
  • but users install vulnerable web applications
  • or write custom web applications having easily-identified and easily-exploited flaws
rootkits
Rootkits
  • allow attacker to cover their tracks
  • if successfully installed before detection, all is very nearly lost
  • originally collections of hacked commands
    • hiding attacker’s files, directories, processes
  • now use loadable kernel modules
    • intercepting system calls in kernel-space
    • hiding attacker from standard commands
  • may be able to detect with chkrootkit
  • generally have to wipe and rebuild system
linux system hardening
Linux System Hardening
  • consider how to mitigate Linux security risks at system and application levels
  • first look at OS-level security tools and techniques that protect the entire system
os installation
OS Installation
  • security begins with O/S installation
  • especially what software is run
    • since unused applications liable to be left in default, un-hardened and un-patched state
  • generally should not run:
    • X Window system, RPC services, R-services, inetd, SMTP daemons, telnet etc
  • also have some initial system s/w configuration:
    • setting root password
    • creating a non-root user account
    • setting an overall system security level
    • enabling a simple host-based firewall policy
    • enabling SELinux
patch management
Patch Management
  • installed server applications must be:
    • configured securely
    • kept up to date with security patches
  • patching can never win “patch rat-race”
  • have tools to automatically download and install security updates
    • e.g. up2date, YaST, apt-get
    • note should not run automatic updates on change-controlled systems without testing
network access controls
Network Access Controls
  • network a key attack vector to secure
  • TCP wrappers a key tool to check access
    • originally tcpd inetd wrapper daemon
    • before allowing connection to service checks
      • if requesting host explicitly in hosts.allow is ok
      • if requesting host explicitly in hosts.deny is blocked
      • if not in either is ok
    • checks on service, source IP, username
    • now often part of app using libwrappers
network access controls1
Network Access Controls
  • also have the very powerful netfilter Linux kernel native firewall mechanism
    • and iptables user-space front end
  • as useful on firewalls, servers, desktops
  • direct config tricky, steep learning curve
  • do have automated rule generators
  • typically for “personnal” firewall use will:
    • allow incoming requests to specified services
    • block all other inbound service requests
    • allow all outbound (locally-originating) requests
  • if need greater security, manually config
antivirus software
Antivirus Software
  • historically Linux not as vulnerable to viruses
  • more to lesser popularity than security
  • prompt patching was effective for worms
  • but viruses abuse users privileges
  • non-root users have less scope to exploit
    • but can still consume resources
  • growing Linux popularity mean exploits
  • hence antivirus software will more important
    • various commercial and free Linux A/V
user management
User Management
  • guiding principles in user-account security:
    • need care setting file / directory permissions
    • use groups to differentiate between roles
    • use extreme care in granting / using root privs
  • commands: chmod, useradd/mod/del, groupadd/mod/del, passwd, chage
  • info in files /etc/passwd & /etc/group
  • manage user’s group memberships
  • set appropriate password ages
root delegation
Root Delegation
  • have "root can to anything, users do little” issue
  • “su” command allows users to run as root
    • either root shell or single command
    • must supply root password
    • means likely too many people know this
  • SELinux RBAC can limit root authority, complex
  • “sudo” allows users to run as root
    • but only need their password, not root password
    • /etc/sudoers file specifies what commands allowed
  • or configure user/group perms to allow, tricky
logging
Logging
  • effective logging a key resource
  • Linux logs using syslogd or Syslog-NG
    • receive log data from a variety of sources
    • sorts by facility (category) and severity
    • writes log messages to local/remote log files
  • Syslog-NG preferable because it has:
    • variety of log-data sources / destinations
    • much more flexible “rules engine” to configure
    • can log via TCP which can be encrypted
  • should check and customized defaults
log management
Log Management
  • balance number of log files used
    • size of few to finding info in many
  • manage size of log files
    • must rotate log files and delete old copies
    • typically use logrotate utility run by cron
    • to manage both system and application logs
  • must also configure application logging
application security
Application Security
  • this is a large topic
  • many security features are implemented in similar ways across different applications
  • will review issues such as:
    • running as unprivileged user/group
    • running in chroot jail
    • modularity
    • encryption
    • logging
running as unprivileged user group
Running As Unprivileged User/Group
  • every process “runs as” some user
  • extremely important this user is not root
    • since any bug can compromise entire system
  • may need root privileges, e.g. bind port
    • have root parent perform privileged function
    • but main service from unprivileged child
  • user/group used should be dedicated
    • easier to identify source of log messages
running in chroot jail
Running in chroot Jail
  • chroot confines a process to a subset of /
    • maps a virtual “/” to some other directory
    • useful if have a daemon that should only access a portion of the file system, e.g. FTP
    • directories outside the chroot jail aren’t visible or reachable at all
  • contains effects of compromised daemon
  • complex to configure and troubleshoot
    • must mirror portions of system in chroot jail
modularity
Modularity
  • applications running as a single, large, multipurpose process can be:
    • more difficult to run as an unprivileged user
    • harder to locate / fix security bugs in source
    • harder to disable unnecessary functionality
  • hence modularity a highly prized feature
    • providing a much smaller attack surface
  • cf. postfix vs sendmail, Apache modules
encryption
Encryption
  • sending logins & passwords or application data over networks in clear text exposes them to network eavesdropping attacks
  • hence many network applications now support encryption to protect such data
    • often using OpenSSL library
  • may need own X.509 certificates to use
    • can generate/sign using openssl command
    • may use commercial/own/free CA
logging1
Logging
  • applications can usually be configured to log to any level of detail (debug to none)
  • need appropriate setting
  • must decide if use dedicated file or system logging facility (e.g. syslog)
    • central facility useful for consistent use
  • must ensure any log files are rotated
mandatory access controls
Mandatory Access Controls
  • Linux uses a DAC security model
  • but Mandatory Access Controls (MAC) impose a global security policy on all users
    • users may not set controls weaker than policy
    • normal admin done with accounts without authority to change the global security policy
    • but MAC systems have been hard to manage
  • Novell’s SuSE Linux has AppArmor
  • RedHat Enterprise Linux has SELinux
  • pure SELinux for high-sensitivity, high-security
selinux
SELinux
  • is NSA's powerful implementation of mandatory access controls for Linux
  • Linux DACs still applies, but if it allows the action SELinux then evaluates it against its own security policies
  • "subjects" are processes (run user cmds)
  • actions are "permissions”
  • objects not just files & dirs
  • to manage complexity SELinux has:
    • "that which is not expressly permitted, is denied”
    • groups of subjects, permissions, and objects
security contexts
Security Contexts
  • each individual subject & object in SELinux is governed by a security context being a:
    • user - individual user (human or daemon)
      • SELinux maintains its own list of users
      • user labels on subjects specify account's privileges
      • user labels on objects specify its owner
    • role - like a group, assumed by users
      • a user may only assume one role at a time,
      • may only switch roles if and when authorized to do so
    • domain (type) - a sandbox being a combination of subjects and objects that may interact with each other
  • this model is called Type Enforcement (TE)
decision making in selinux
Decision Making in SELinux
  • two types of decisions:
  • access decisions
    • when subjects do things to objects that already exist, or create new things in expected domain
  • transition decisions
    • invocation of processes in different domains than the one in which the subject-process is running
    • creation of objects in different types (domains) than their parent directories
    • transitions must be authorized by SELinux policy
rbac and mls controls
RBAC and MLS Controls
  • have Role Based Access Control (RBAC)
    • rules specify roles a user may assume
    • other rules specify circumstances when a user may transition from one role to another
  • and Multi Level Security (MLS)
    • concerns handling of classified data
      • “no read up, no write down”
    • MLS is enforced via file system labeling
selinux policy management
SELinux Policy Management
  • creating and maintaining SELinux policies is complicated and time-consuming
  • a single SELinux policy may consist of hundreds of lines of text
  • RHEL has a default “targeted” policy
    • defines types for selected network apps
    • allows everything else to use DAC controls
  • have a range of SELinux commands
    • see additional references for details
novell apparmor
Novell AppArmor
  • Novell’s MAC for SuSE Linux
    • enforced at kernel level
    • using Linux Security Modules
  • restricts behavior of selected applications in a very granular but targeted way
    • hence a compromised root application's access will be contained
    • has no controls addressing data classification
    • hence only a partial MAC implementation
  • non-protected apps just use Linux DAC
summary
Summary
  • reviewed Linux security model and DAC
  • vulnerabilities
  • O/S and application hardening
  • MAC, SELinux and AppArmor
computer security principles and practice1

Computer Security: Principles and Practice

Chapter 24 – Windows and Windows Vista Security

First Edition

by William Stallings and Lawrie Brown

Lecture slides by Lawrie Brown

windows and windows vista security
Windows and Windows Vista Security
  • Windows is the world’s most popular O/S
  • advantage is that security enhancements can protect millions of nontechnical users
  • challenge is that vulnerabilities in Windows can also affect millions of users
  • will review overall security architecture of Windows 2000 and later (but not Win9X)
  • then security defenses built into Windows
windows security architecture
Windows Security Architecture
  • Security Reference Monitor (SRM)
    • a kernel-mode component that performs access checks, generates audit log entries, and manipulates user rights (privileges)
  • Local Security Authority (LSA)
    • responsible for enforcing local security policy
  • Security Account Manager (SAM)
    • a database that stores user accounts and local users and groups security information
    • local logins perform lookup against SAM DB
    • passwords are stored using MD4
windows security architecture1
Windows Security Architecture
  • Active Directory (AD)
    • Microsoft’s LDAP directory
    • all Windows clients can use AD to perform security operations including account logon
    • authenticate using AD when the user logs on using a domain rather than local account
    • user’s credential information is sent securely across the network to be verified by AD
  • WinLogon (local) and NetLogon (net) handle login requests
local vs domain accounts
Local vs Domain Accounts
  • a networked Windows computer can be:
  • domain joined
    • can login with either domain or local accounts
    • if local may not access domain resources
    • centrally managed and much more secure
  • in a workgroup
    • a collection of computers connected together
    • only local accounts in SAM can be used
    • no infrastructure to support AD domain
windows login example
Windows Login Example
  • domain admin adds user’s account info (name, account, password, groups, privileges)
  • account is represented by a Security ID (SID)
    • unique to each account within a domain
    • of form: S-1–5–21-AAA-BBB-CCC-RRR
  • username in one of two forms:
    • SAM format: DOMAIN\Username
    • User Principal Name (UPN): username@domain.company.com
  • login using username & password or smartcard
  • issued with token (SID, groups, privileges)
    • assigned to every process run by user
windows privileges
Windows Privileges
  • are systemwide permissions assigned to user accounts
    • e.g. backup computer, or change system time
  • some are deemed “dangerous” such as:
    • act as part of operating system privilege
    • debug programs privilege
    • backup files and directories privilege
  • others are deemed “benign” such as
    • bypass traverse checking privilege
access control lists
Access Control Lists
  • two forms of access control list (ACL):
  • Discretionary ACL (DACL)
    • grants or denies access to protected resources such as files, shared memory, named pipes etc
  • System ACL (ACL)
    • used for auditing and in Windows Vista to enforce mandatory integrity policy
access control lists1
Access Control Lists
  • objects needing protection are assigned a DACL (and possible SACL) that includes
    • SID of the object owner
    • list of access control entries (ACEs)
  • each ACE includes a SID & access mask
  • access mask could include ability to:
    • read, write, create, delete, modify, etc
  • access masks are object-type specific
    • e.g. service abilities are create, enumerate
security descriptor sd
Security Descriptor (SD)
  • data structure with object owner, DACL, & SACL
    • e.g.

Owner: CORP\Blake

ACE[0]: Allow CORP\Paige Full Control

ACE[1]: Allow Administrators Full Control

ACE[2]: Allow CORP\Cheryl Read, Write and Delete

  • have no implied access, if there is no ACE for requesting user, then access is denied
  • applications must request correct type of access
    • if just request “all access” when need less (e.g. read) some user’s who should have access will be denied
more sd s access checks
More SD’s & Access Checks
  • each ACE in the DACL determines access
  • an ACE can be an allow or a deny ACE
  • Windows evaluates each ACE in the ACL until access is granted or explicitly denied
  • so deny ACEs come before allow ACEs
    • default if set using GUI
    • explicitly order if create programmatically
  • when user attempts to access a protected object, the O/S performs an access check
    • comparing user/group info with ACE’s in ACL
impersonation
Impersonation
  • process can have multiple threads
    • common for both clients and servers
  • impersonation allows a server to serve a user, using their access privileges
    • e.g. ImpersonateNamedPipeClient function sets user’s token on the current thread
    • then access checks for that thread are performed against this token not server’s
    • with user’s access rights
mandatory access control
Mandatory Access Control
  • have Integrity Control in Windows Vista
  • that limits operations changing an object’s state
  • objects and principals are labeled (using SID) as:
    • Low integrity (S-1-16-4096)
    • Medium integrity (S-1-16-8192)
    • High integrity (S-1-16-12288)
    • System integrity (S-1-16-16384)
  • when write operation occurs first check subject’s integrity level dominates object’s integrity level
  • much of O/S marked medium or higher integrity
windows vulnerabilities
Windows Vulnerabilities
  • Windows, like all O/S’s, has security bugs
    • and bugs have been exploited by attackers to compromise customer operating systems
  • Microsoft now uses process improvement called the Security Development Lifecycle
    • net effect approx 50% reduction in bugs
  • Windows Vista used SDL start to finish
  • IIS v6 (in Windows Server 2003) had only 3 vulnerabilities in 4 years, none critical
windows security defenses
Windows Security Defenses
  • attackers are now criminals rather than young, anarchic miscreants, and are highly motivated by money
  • have categories of security defenses:
    • account defenses
    • network defenses
    • buffer overrun defenses.
    • browser defenses
windows system hardening
Windows System Hardening
  • process of shoring up defenses, reducing exposed functionality, disabling features
    • known as attack surface reduction
    • use 80/20 rule on features
    • not always achievable
    • e.g. requiring RPC authentication in XP SP2
    • e.g. strip mobile code support on servers
  • servers easier to harden:
    • are used for very specific and controlled purposes
    • perceive server users are administrators with better computer configuration skills than typical users
account defenses
Account Defenses
  • user accounts can have privileged SIDs
  • least privilege dictates that users operate with just enough privilege for tasks
  • Windows XP users in local Administrators
    • for application compatibility reasons
    • can use “Secondary Logon” to run apps
    • also restricted tokens reduce per-thread privilege
  • Windows Vista reverses default with UAC
    • users prompted to perform a privileged operation
    • unless admin on Server
low privilege service accounts
Low Privilege Service Accounts
  • Windows services are long-lived processes started after booting
    • many ran with elevated privileges
    • but many do not need elevated requirements
  • Windows XP added Local Service and Network service accounts
    • allow a service local or network access
    • otherwise operate at much lower privilege level
  • Windows XP SP2 split RPC service (RPCSS) in two (RPCSS and DCOM Server Process)
    • example of least privilege in action, see also IIS6
stripping privileges
Stripping Privileges
  • another defense is to strip privileges from an account soon after an application starts
    • e.g. Index server process runs as system to access all disk volumes
    • but then sheds any unneeded privileges as soon as possible
    • using AdjustTokenPrivileges
  • Windows Vista can define privileges required by a service
    • using ChangeServiceConfig2
network defenses
Network Defenses
  • need more than user defenses
  • vulnerable to attack via network service
  • have IPSec and IPv6 with authenticated network packets enabled by default in Windows Vista
    • IPv4 also enabled by default, expect less use
  • have built-in software firewall
    • block inbound connections on specific ports
      • Vista can allow local net access only
    • optionally block outbound connections (Vista)
    • default was off (XP) but now default on (Vista)
buffer overrun defenses
Buffer Overrun Defenses
  • many compromises exploit buffer overruns
  • Windows Vista has “Stack-Based Buffer Overrun Detection (/GS)” default enabled
    • source code compiled with special /GS option
    • does not affect every function; only those with at least 4-bytes of contiguous stack data and that takes a pointer or buffer as an argument
  • defends against “classic stack smash”
buffer overrun defenses1
Buffer Overrun Defenses
  • No eXecuteNamed (NX) / Data Execution Prevention (DEP) / eXecution Disable (XD)
    • prevent code executing in data segments
    • as commonly used by buffer overrun exploits
    • applications linked with /NXCOMPAT option
  • Stack Randomization (Vista only)
    • randomizes thread stack base addresses
  • Heap-based buffer overrun defenses:
    • add and check random value on each heap block
    • heap integrity checking
    • heap randomization (Vista only)
other defenses
Other Defenses
  • Image Randomization
    • O/S boots in one of 256 configurations
    • makes O/S less predictable for attackers
  • Service Restart Policy
    • services can be configured to restart if fail
    • great for reliability but lousy for security
    • Vista sets some critical services so can only restart twice, then manual restart needed
    • gives attacker only two attempts
browser defenses
Browser Defenses
  • web browser is a key point of attack
    • via script code, graphics, helper objects
  • Microsoft added many defenses to IE7
    • ActiveX opt-in
      • unloads ActiveX controls by default
      • when any then first run prompts user to confirm
    • protected mode
      • IE runs at low integrity level (see earlier)
      • so more difficult for malware to manipulate O/S
cryptographic services
Cryptographic Services
  • low-level crypto for encryption, hashing, signing
  • Encrypting File System (EFS)
    • allows files / directories to be encrypted / decrypted transparently for authorized users
    • generates random key, protected by DPAPI
  • Data Protection API (DPAPI)
    • manages encryption key maintenance protection
    • keys derived in part from user’s password
  • BitLocker Drive Encryption
    • encrypts an entire volume with AES
    • key either on USB or TPM chip
summary1
Summary
  • Windows security architecture
  • vulnerabilities
  • security defenses
    • account, network, buffer, browser
  • crypto services