RH253 Unit 2 System Service Access Controls

Objectives

Upon completion of this unit, you should be able to:

1) Understand how services are managed

2) Learn common traits among services

3) Describe service configuration resources

4) Implement access controls

5) SELinux overview

6) SELinux Management

 

System Resources Managed by init

1) Services listening for serial protocol connections

- a serial console

- a modem

2) Configured in /etc/inittab

3) Calls the command rc to spawn initialization scripts

4) Calls a script to start the X11 display manager

5) Provides respawn capability

 

System Initialization and Service Management

1) Commonly referred to as “System V” or “SysV”

- Many scripts organized by file system directory semantics

- Resource service are either enabled or disabled

2) Several configuration files are often used

3) Most services start one or more processes

4) Commands are “wrapped” by scripts

5) Services are managed by these scripts, found in /etc/init.d/

6) Examples:

- /etc/init.d/network status

- service network status

chkconfig

1) Manages service definitions in run levels

2) To start the cups service on boot: chkconfig cups on

3) Does not modify current run state of System V services

4) Used for standalone and transient services

5) Called by other applications, including system-config-services

6) To list run level assignments, run chkconfig –list

 

Initialization Script Management

1) Determine which services are configured to run as system boot

- chkconfig –list

2) Shows which services should run

3) Only reports the status of the symbolic links it manages

 

xinetd Managed Services

1) Transient servcies are managed by the xinetd service

2) Incoming requests are brokered by xinetd

3) Configuration files: /etc/xinetd.conf, /etc/xinetd.d/service

4) Linked with libwrap.so

5) Services controlled with chkconfig: chkconfig tftp on

 

xinetd Default Controls

1) Top-level configuration file: /etc/xinetd.conf

 

xinetd Service Configuration

1) Service specific configuration: /etc/xinetd.d/service

 

xinetd Access Controls

1) Syntax

- Allow with only_from = host_pattern

- Deny with no_access = host_pattern

- The most exact specification is authoritative

 

Host Pattern Access Controls

1) Host masks for xinetd may be:

- numeric address

- network name (from /etc/networks)

- hostname or domain (.domain.com)

- IP address/netmask range

2) Number of simultaneous connections

- Syntax: per_source = 2

- Cannot exceed maximum instances

 

The /etc/sysconfig/files

1) Some services are configured for how they run

- named

- sendmail

- dhcpd

- samba

- init

- syslog

 

Service and Application Access Controls

1)  Service-specific configuration

- Daemons like httpd, smbd, squid, etc. provicde service-specific security mechanisms

2) General configuration

- All program linked with libwrap.so use common configuration files

- Because xinetd is linked with libwrap.so, its services are effected

- Checked for host and/or remote user name

 

tcp_wrapper Configuration

1) Three stages of access checking

- Is access explicilty permitted?

- Otherwise, is access explicitly denied?

- Otherwise, by default, permit access!

2) Configuration stored in two files:

- Permission in /etc/hosts.allow

- Denials in /etc/hosts.deny

3) Basic syntax:

daemon_list: client_list [:option]

 

Daemon Specification

1) Daemon name:

- Application pass name of their executable

- Multiple services can be specified

- Use wildcard ALL to match all daemons

- Limitations exist for certain daemons

2) Advance syntax:

daemon@host: client_list …

Client Specification

1) Host specification

- by IP address

- by name

- by netmaks

- by network name

 

Macro Definitions

1) Host name macros

- LOCAL

- KNOWN, UNKNOWN, PARANOID

2) Host and service macro

- ALL

3) EXCEPT

- Can be used for client and service list

- Can be nested

 

Extended Options

1) Syntax

daemon_list: client_list [:opt1 :opt2…]

2) spawn

- Can be used to start addtional programs

- Special expansions are available (%c, %s)

3) Example:

in.telnetd: ALL : spawn echo “login attempt from %c to s% /

| mail –s warning root

4) DENY

- Can be used as an option in hosts.allow

5) EXAMPLE

ALL: ALL: DENY

 

A tcp_wrappers Example

# /etc/hosts.allow

vsftpd: 192.168.0.

in.telnetd, sshd: .example.com 192.168.2.5

# /etc/hosts.deny

ALL : ALL

 

xinetd and tcp_wrappers

1) xinetd provides its own set of access control functions

- host-based

- time-based

2) tcp_wrappers is still used

- xinetd is compiled with libwrap support

- If libwrap.so allows the connection, then xinetd security configuration is evaluated

 

SELinux

1) Mandatory Access Control (MAC) –vs- Discretionary Access Control (DAC)

2) A rule set called the policy determines how strict the control

3) Processes are either restricted or unconfined

4) The policy defines what resources restricted processes are allowed to access

5) Any action that is not explicitly allowed, by default, denied

 

SELinux, continued

1) All files and processes have a security context

2) The context has serveral elements, depending on the security needs:

- user:role:type:sensitivity:category

- user_u:object_r:tmp_t:s0:c0

- Not all systems will display s0:c0

3) ls –Z

4) ps –Z

- Usually paired with other options, such as –e

 

SELinux: Targeted Policy

1) The targeted policy is loaded at install time

2) Most local processes are unconfigured

3) Principally uses the type element for type enforcement

4) The security context can be changed with chcon: chcon –t tmp_t /etc/hosts

5) Safer to use restorecon: restorecon /etc/hosts

 

SELinux: Management

1) Modes: Enforcing, Permissive, Disabled

- Changing enforcement is allowed in the Targeted policy

- getenforce

- setenforce 0 | 1

- Disable from GRUB with selinux=0

2) system-config-selinux

- Changes mode, and targeted policy controls. Mode change requires system reboot

- Booleans

3) /etc/sysconfig/selinux

4) setroubleshooted

- Advises on how to avoid errors, not ensure security!

SELinux: semanage

1) Some features controlled by semanage

2) Recompiles small portions of the policy

3) semanage function –l

4) Most useful in high security environments

 

SELinux: File Types

1) A managed service type is called its domain

2) Allow rules in the policy define what file types a domain may access

3) The policy is stored in a binary format, obscuring the rules from casual viewing

4) Types can be viewed with semanage: semanage fcontext –l

5) public_content_t

 

End of Unit 2

1) Questions and Answers

2) Summary

- Address questions

- Preparition for lab

- Goals

- Sequences

- Deliverables

- Please ask the instructor for assistance when needed

- SELinux Management