M eeting Critical Security Objectives with Security-Enhanced Linux - - PowerPoint PPT Presentation

▶
m eeting critical security objectives with security
SMART_READER_LITE
LIVE PREVIEW

M eeting Critical Security Objectives with Security-Enhanced Linux - - PowerPoint PPT Presentation

Apr 22, 2023 46 likes •482 views

M eeting Critical Security Objectives with Security-Enhanced Linux Peter A. Loscocco Information Assurance Research G roup National Security Agency Co-author: Stephen D. Smalley, NAI Labs 1 roup Inform ation A ssurance R esearch G

slide-1
SLIDE 1

■ Inform

ation A ssurance R esearch G roup ■

1

M eeting Critical Security Objectives with Security-Enhanced Linux

Peter A. Loscocco Information Assurance Research G roup National Security Agency Co-author: Stephen D. Smalley, NAI Labs

slide-2
SLIDE 2

■ Inform

ation A ssurance R esearch G roup ■

2

Presentation Outline

  • O

perating system security

  • The Flask architecture
  • Security-enhanced Linux
  • Example security server
  • Meeting critical security objectives
  • Future Direction
slide-3
SLIDE 3

■ Inform

ation A ssurance R esearch G roup ■

3

The Need for Secure OS

  • Increasing risk to valuable information
  • Dependence on O

S protection mechanisms

  • Inadequacy of mainstream operating systems
  • Key missing feature: Mandatory Access Control (MAC)

– Adm inistratively-set security policy – Control over all subjects and objects in system – Decisions based on all security-relevant inform ation

slide-4
SLIDE 4

■ Inform

ation A ssurance R esearch G roup ■

4

W hy is DAC inadequate?

  • Decisions are only based on user identity and ownership
  • No protection against malicious software
  • Each user has complete discretion over his objects
  • O

nly two major categories of users: superuser and other

  • Many system services and privileged programs must run with

coarse-grained privileges if not as superuser

slide-5
SLIDE 5

■ Inform

ation A ssurance R esearch G roup ■

5

W hat can M AC offer?

  • Strong separation of security domains
  • System and data integrity
  • Ability to limit program privileges
  • Protection against tamper and bypass
  • Processing pipelines guarantees
  • Authorization limits for legitimate users
slide-6
SLIDE 6

■ Inform

ation A ssurance R esearch G roup ■

6

M AC Im plem entation Issues

  • Must overcome limitations of traditional implementations

– M

  • re than just M

ultilevel Security – Address integrity, least privilege, separation of duty issues – Com plete control using needed security relevant inform ation – Control relationships between subjects and code

  • Policy flexibility required

– One size does not fit all! – Ability to change the m

  • del of security

– Ability to express different policies within given m

  • del

– Separation of policy from enforcem ent

  • Maximize security transparency
slide-7
SLIDE 7

■ Inform

ation A ssurance R esearch G roup ■

7

Custom ize according to need

  • Separation policies

– Establishing Legal Restrictions on data – Restrictions to classified/com partm ented data

  • Confinement policies

– Restricting web server access to authorized data – M inim izing dam age from viruses and other m alicious code

  • Integrity policies

– Protecting applications from m

  • dification

– Preventing unauthorized m

  • difications of databases
  • Invocation policies

– Guaranteeing that data is processed as required – Enforcing encryption policies

slide-8
SLIDE 8

■ Inform

ation A ssurance R esearch G roup ■

8

Security Solutions with Flexible M AC

  • Confines malicious code

– Can safely run code of uncertain pedigree – Constrains code inserted via buffer overflow attacks – Lim its virus propagation

  • Allows effective decomposition of root

– Root no longer all powerful – Lim its each root function to needed privilege – Elim inates m

  • st privilege elevation attacks
  • Allows effective assignment of privilege

– Servers need not run with com plete access – Servers and needed resources can be isolated – Separate protections for system logs

slide-9
SLIDE 9

■ Inform

ation A ssurance R esearch G roup ■

9

Toward a New Form

  • f M

AC

  • Research by NSA with help from SCC
  • G

eneralized from prior Type Enforcement work

  • Provide flexible support for security policies
  • Cleanly separate policy from enforcement
  • Address limitations of traditional MAC
  • DTMach, DTO

S, Flask

slide-10
SLIDE 10

■ Inform

ation A ssurance R esearch G roup ■

10

The Flask Security Architecture

  • Cleanly separates policy from enforcement.
  • W

ell-defined policy interfaces.

  • Support for policy changes.
  • Allows users to express policies naturally.
  • Fine-grained controls over kernel services.
  • Caching to minimize performance overhead.
  • Transparent to applications and users.
slide-11
SLIDE 11

■ Inform

ation A ssurance R esearch G roup ■

11

The Flask Security Architecture

Subject, object, class, requested

Object Manager Policy Enforcement Object/SID Mapping Security Server Policy Decisions SID/Context Mapping Access Vector Cache

Yes/no Access vector

slide-12
SLIDE 12

■ Inform

ation A ssurance R esearch G roup ■

12

Policy Decisions

  • Labeling Decisions: O

btaining a label for a new subject or

  • bject.
  • Access Decisions: Determining whether a service on an object

should be granted to a subject.

  • Polyinstantiation Decisions: Determining where to redirect a

process when accessing a polyinstantiated object.

slide-13
SLIDE 13

■ Inform

ation A ssurance R esearch G roup ■

13

Policy Changes

  • Interfaces to AVC for policy changes
  • Callbacks to O

bject Managers for retained permissions

  • Sequence numbers to address interleaving
  • Revalidation of permissions on use
slide-14
SLIDE 14

■ Inform

ation A ssurance R esearch G roup ■

14

Controlled Services

  • Permissions are defined on objects and grouped together into
  • bject classes
  • Examples

– Process: code execution, transitions, entrypoints, signals, wait, ptrace, capabilities, etc. – File: fd inheritance and transfer, accesses to files, directories, file system s – Socket: accesses to sockets, m essages, network interfaces, hosts – System V IPC: accesses to sem aphores, m essage queues, shared m em

  • ry

– Security: accesses to security server services

slide-15
SLIDE 15

■ Inform

ation A ssurance R esearch G roup ■

15

Security Server Interface

  • O

bject Labeling

– Request SID to label a new object

  • int security_transition_sid(ssid, tsid, tclass, *out_sid)

– Exam ple of usage for new file label

  • error = security_transition_sid(current->sid, dir->i_sid, FILE, &sid);
slide-16
SLIDE 16

■ Inform

ation A ssurance R esearch G roup ■

16

Security Server Interface (cont.)

  • Access Decisions

– Request Access Vector for a given object class/perm ission

  • int security_com

pute_av(ssid, tsid, tclass, requested, *allowed, *decided, *seqno);

– Ignores access vectors for auditing and requests of notifications of com pleted operations

slide-17
SLIDE 17

■ Inform

ation A ssurance R esearch G roup ■

17

Security Server Interface (cont.)

  • Access Vector Cache (AVC)

– security_com pute_av() called indirectly through AVC

  • int avc_has_perm

_ref(ssid, tsid, tclass, requested, *aeref, *auditdata)

– aeref is hint to cache entry. If invalid then security_com pute_av() is called

  • File permission check shortcuts

– int dentry_m ac_perm ission(struct dentry *d, access_vector_t av )

slide-18
SLIDE 18

■ Inform

ation A ssurance R esearch G roup ■

18

  • unlink from fs/namei.c:vfs_unlink()

error = dentry_m ac_perm ision(dentry, FILE_UNLINK); if (error) return error; – Additional directory-based checks for search and rem

  • ve_nam

e perm issions

  • Process to socket check from net/ipv4/af_inet:inet_bind()

lock_sock(sk); ret = avc_has_perm _ref(current->sid,sk->sid,sk->sclass, SOCKET_BIND &sk->avcr); release_sock(sk); if (ret) return ret;

Perm ission Checking Exam ples

slide-19
SLIDE 19

■ Inform

ation A ssurance R esearch G roup ■

19

Perm ission Checking Exam ples

  • execve() from

fs/exec.c:prepare_binprm ()

  • Also checks file:execute, fd:inherit, process:ptrace

if (!bprm

  • >sid) {

retval = security_transition_sid(current->sid, inode->i_sid, S EC C LA SS _PR O C ES S, & bprm

  • >sid);

if (retval) return retval;} if (current->sid != bprm

  • >sid &

& !bprm

  • >sh_bang){

retval = A VC _H AS _PE R M _A U D IT(current->sid, bprm

  • >sid,

P R O C E SS , TR A N SITIO N , &ad); if (retval) return retval; retval = process_file_m ac_perm ission(bprm

  • >sid, bprm
  • >file,

P R O C E SS _EN TR YP O IN T); if (retval) return retval;} retval = process_file_m ac_perm ission(bprm

  • >sid, bprm
  • >file,

P R O C E SS _EX EC U TE); if (retval) return retval;

slide-20
SLIDE 20

■ Inform

ation A ssurance R esearch G roup ■

20

API Enhancem ents

  • Existing Linux API calls unchanged
  • New API calls for security-aware applications: execve_secure,

mkdir_secure, stat_secure, socket_secure, accept_secure, etc.

  • New API calls for application policy enforcers:

security_compute_av, security_transition_sid, etc.

slide-21
SLIDE 21

■ Inform

ation A ssurance R esearch G roup ■

21

Exam ple Security Server

  • Implements combination of Role-Based Access Control, Type

Enforcement, optional Multi-Level Security.

  • Labeling, access, and polyinstantiation decisions defined

through set of configuration files.

  • Example policy configuration provided.
slide-22
SLIDE 22

■ Inform

ation A ssurance R esearch G roup ■

22

Exam ple Policy Configuration: TE Concepts

  • Domains for processes, types for objects.
  • Specifies allowable accesses by domains to types.
  • Specifies allowable interactions among domains.
  • Specifies allowable and automatic domain transitions.
  • Specifies entrypoint and code execution restrictions for domains.
slide-23
SLIDE 23

■ Inform

ation A ssurance R esearch G roup ■

23

Type Enforcem ent: Dom ains

init_t

init_exec_t

getty_t

getty_exec_t

login_t

login_exec_t

user_t

shell_exec_t

user_netscape_t

netscape_exec_t

initrc_t

initrc_exec_t

sendmail_t

sendm ail_exec_t

klogd_t

klogd_exec_t

slide-24
SLIDE 24

■ Inform

ation A ssurance R esearch G roup ■

24

Type Enforcem ent: Types

/:

root_t

bin:

bin_t

var:

var_t

log:

var_log_t

wtmp:

wtm p_t

login:

login_exec_t

kmem:

m em

  • ry_device_t

dev:

device_t

slide-25
SLIDE 25

■ Inform

ation A ssurance R esearch G roup ■

25

Sam ple TE Rules

allow sendmail_t smtp_port_t:tcp_socket name_bind; type_transition getty_t login_exec_t:process local_login_t;

slide-26
SLIDE 26

■ Inform

ation A ssurance R esearch G roup ■

26

Exam ple Policy Configuration: RBAC concepts

  • Roles for processes
  • Specifies domains that can be entered by each role
  • Specifies roles that are authorized for each user
  • Initial domain associated with each user role
  • Role transitions are typically explicit, e.g. login or newrole
slide-27
SLIDE 27

■ Inform

ation A ssurance R esearch G roup ■

27

Role-Based Access Control: Roles

system_r

init_t getty_t klogd_t sendmail_t

user_r

user_t user_netscape_t passwd_t

sysadm_r

sysadm_t insmod_t fsadm_t

slide-28
SLIDE 28

■ Inform

ation A ssurance R esearch G roup ■

28

Exam ple Policy Configuration: Security Objectives

  • Protect kernel integrity, including boot files, kernel modules,

sysctl variables

  • Protect integrity of system software, configuration files, and logs
  • Protect administrator role and domain
  • Confine system processes and privileged programs
  • Protect against execution of malicious software
slide-29
SLIDE 29

■ Inform

ation A ssurance R esearch G roup ■

29

Lim iting raw access to data

  • Controlling fsck and related utilities

allow fsadm _t fsadm _exec_t:process { entrypoint execute }; allow fsadm _t fixed_disk_device_t:blk_file { read write }; allow initrc_t fsadm _t:process transition; allow sysadm _t fsadm _t:process transition;

slide-30
SLIDE 30

■ Inform

ation A ssurance R esearch G roup ■

30

Lim iting raw access to data

  • G

ranting access to klogd

allow klogd_t klogd_exec_t:process { entrypoint execute }; allow klogd_t m em

  • ry_device_t:chr_file

{ read write }; allow initrc_t klogd_t:process transition;

slide-31
SLIDE 31

■ Inform

ation A ssurance R esearch G roup ■

31

Kernel integrity protection

  • Protecting /boot files

allow initrc_t boot_t:dir { read search add_nam e rem

  • ve_nam

e }; allow initrc_t boot_runtim e_t:file { create write unlink }; type_transition initrc_t boot_t:file boot_runtim e_t;

slide-32
SLIDE 32

■ Inform

ation A ssurance R esearch G roup ■

32

Kernel integrity protection

  • Controlling use of insmod program

allow sysadm _t insm

  • d_exec_t:file x_file_perm

s; allow sysadm _t insm

  • d_t:process transition;

allow insm

  • d_t insm
  • d_exec_t:process

{ entrypoint execute }; allow insm

  • d_t sysadm

_t:fd inherit_fd_perm s; allow insm

  • d_t self:capability sys_m
  • dule;

allow insm

  • d_t sysadm

_t:process sigchld;

slide-33
SLIDE 33

■ Inform

ation A ssurance R esearch G roup ■

33

System file integrity protection

  • Separate types for system programs

– e.g. bin_t, sbin_t

  • Separate types for system configuration files

– e.g. etc_t

  • Separate type for shared libraries

– e.g. shlib_t

  • Separate types for system logs

– e.g. wtm p_t

  • Separate type for dynamic linker

– e.g. ld_so_t

slide-34
SLIDE 34

■ Inform

ation A ssurance R esearch G roup ■

34

System file integrity protection

  • G

ranting sendmail accesses

allow sendm ail_t etc_aliases_t:file { read write }; allow sendm ail_t etc_m ail:dir { read search add_nam e rem

  • ve_nam

e }; allow sendm ail_t etc_m ail_t:file { create read write unlink };

  • G

ranting logfile accesses

allow local_login_t wtm p_t:file { read write }; allow rem

  • te_login_t wtm

p_t:file { read write }; allow utem pter_t wtm p_t:file { read write };

slide-35
SLIDE 35

■ Inform

ation A ssurance R esearch G roup ■

35

Confining privileged processes

  • excerpt for sendmail

allow sendm ail_t sm pt_port_t:tcp_socket nam e_bind; allow sendm ail_t m ail_spool_t:dir { read search add_nam e rem

  • ve_nam

e }; allow sendm ail_t m ail_spool_t:file { create read write unlink }; allow sendm ail_t m queue_spool_t:dir { read search add_nam e rem

  • ve_nam

e }; allow sendm ail_t m queue_spool_t:file { create read write unlink };

slide-36
SLIDE 36

■ Inform

ation A ssurance R esearch G roup ■

36

Confining privileged processes

  • excerpt for ftpd

allow ftpd_t wtm p_t:file append; allow ftpd_t var_log_t:file append; allow ftpd_t ls_exec_t:process execute;

slide-37
SLIDE 37

■ Inform

ation A ssurance R esearch G roup ■

37

Separating Processes

  • Access across domains restricted to privilege processes

– signals, ptrace, /proc

  • Access to temporary files controlled

allow user_t tm p_t:dir { read search add_nam e rem

  • ve_nam

e } ; allow user_t user_tm p_t:file { creat read write unlink }; type_transition user_t tm p_t:file user_tm p_t;

  • Similar controls for home directories and terminal devices
slide-38
SLIDE 38

■ Inform

ation A ssurance R esearch G roup ■

38

Adm inistrator dom ain protection

  • Controlling access to sysadm_t

type_transition getty_t login_exec_t:process local_login_t; allow local_login_t sysadm _t:process transition; allow newrole_t sysadm _t:process transition;

  • Execution limited to approved types
  • Separation from other domains
slide-39
SLIDE 39

■ Inform

ation A ssurance R esearch G roup ■

39

M alicious software protection

  • Example putting netscape in its own domain

type_transition user_t netscape_exec_t:process user_netscape_t; allow user_t netscape_exec_t:process { entrypoint execute } ; allow user_netscape_t user_netscape_rw_t:file { read write create unlink };

slide-40
SLIDE 40

■ Inform

ation A ssurance R esearch G roup ■

40

Perform ance

  • Initial performance measurements reported at

2001 Usenix Conference

  • Benchmark Summary

– M acrobenchm arks showed no m easurable overhead – M icrobenchm arks showed sm all fixed overhead proportional to com plexity

  • f perm

ission checks – Should be treated as upper bound - no optim ization done

  • O

ngoing performance work (IBM W atson)

– Scalability and locking issues

slide-41
SLIDE 41

■ Inform

ation A ssurance R esearch G roup ■

41

Ongoing and future work

  • Define generalized hooks for kernel (LSM Project)
  • Integrate with IPSEC/IKE and extend to support packet labeling

and policy-based protection.

  • Implement labeling and controls for NFS.
  • Implement complete polyinstantiation support.
  • Develop policy specification and analysis tools
slide-42
SLIDE 42

■ Inform

ation A ssurance R esearch G roup ■

42

Linux Security M

  • dule Project
  • G
  • al is to develop common set of kernel hooks to allow security

LKMs to be defined

  • Hosted by W

ireX

– http://lsm .im m unix.com / – linux-security-m

  • dule@

wirex.com

  • Status

– Patch to 2.4.6 kernel w/m

  • st hooks defined

– Currently working on networking hooks

  • SELinux LKM using LSM patch ready

– Available at http://www.nsa.gov/selinux/ soon

slide-43
SLIDE 43

■ Inform

ation A ssurance R esearch G roup ■

43

Questions?

Available at: http://www.nsa.gov/selinux/ Mailing list: Send ‘subscribe selinux’ to majordomo@ tycho.nsa.gov email: loscocco@ tycho.nsa.gov ssmalley@ nai.com