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