0% found this document useful (0 votes)
98 views9 pages

Lab Manual

The document discusses implementing mandatory access control (MAC) on a network. It describes loading MAC security policy modules in Linux to control access based on privileges across subjects and objects. It provides details on configuring specific MAC policy modules like mac_seeotheruids, mac_bsdextended, and mac_ifoff to implement access controls and harden the system.

Uploaded by

Jojo Cansino
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
Download as docx, pdf, or txt
0% found this document useful (0 votes)
98 views9 pages

Lab Manual

The document discusses implementing mandatory access control (MAC) on a network. It describes loading MAC security policy modules in Linux to control access based on privileges across subjects and objects. It provides details on configuring specific MAC policy modules like mac_seeotheruids, mac_bsdextended, and mac_ifoff to implement access controls and harden the system.

Uploaded by

Jojo Cansino
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1/ 9

INFORMATION TECHNOLOGY EDUCATION DEPARTMENT

ITELEC5 NETWORK SECURITY

EXERCISE

ACCESS CONTROL

IMPLEMENTING MAC(Mandatory Access Control)

I. Objectives 1. To implement a mac to a certain network 2. To create a module defining mac security 3. To work with linux serves for implementation 4. To work with access control models 5. To describe how MAC handles security administration and access controls base on priviledges

Before reading this exercise you should know:

How to manage UNIX Be familiar with the basic kernel configuration Be familiar with security and how it pertains to CIA

II. Basic Information

Two of the most significant new security mechanisms are file system Access Control Lists (ACLs) and Mandatory Access Control (MAC) facilities.

Mandatory Access Control allows new access control modules to be loaded, implementing new security policies. Some provide protections of a narrow subset of the system, hardening a particular service. Others provide comprehensive labeled security across all subjects and objects. The mandatory part of the definition comes from the fact that the enforcement of the controls is done by administrators and the system, and is not left up to the discretion of users as is done with discretionary access control (DAC).

The various security policy modules provided by the MAC framework could be used to protect the network and file systems, block users from accessing certain ports and sockets, and more. Perhaps the best use of the policy modules is to blend them together, by loading several security policy modules at a time for a multi-layered security environment. In a multi-layered security environment, multiple policy modules are in effect to keep security in check. This is different to a hardening policy, which typically hardens elements of a system that is used only for specific purposes. The only downside is administrative overhead in cases of multiple file system labels, setting network access control user by user, etc.

These downsides are minimal when compared to the lasting effect of the framework; for instance, the ability to pick and choose which policies are required for a specific configuration keeps performance overhead down. The reduction of support for unneeded policies can increase the overall

performance of the system as well as offer flexibility of choice. A good implementation would consider the overall security requirements and effectively implement the various security policy modules offered by the framework.

III. Laboratory Procedures:

To create a module: Every module included with the MAC framework may be either compiled into the kernel as noted above or loaded as a run-time kernel module. The recommended method is to add the module name to the
/boot/loader.conf

file so that it will load during the initial boot operation.

Module Classes:

MAC seeotheruids Module

Module name: mac_seeotheruids.ko

Kernel configuration line: options MAC_SEEOTHERUIDS

Boot option: mac_seeotheruids_load="YES"

The mac_seeotheruids(4) module mimics and extends the security.bsd.see_other_uids and security.bsd.see_other_gids sysctl tunables. This option does not require any labels to be set before configuration and can operate transparently with the other modules. After loading the module, the following sysctl tunables may be used to control the features:

security.mac.seeotheruids.enabled

will enable the module's features and

use the default settings. These default settings will deny users the ability to view processes and sockets owned by other users.
security.mac.seeotheruids.specificgid_enabled

will allow a certain group to

be exempt from this policy. To exempt specific groups from this policy, use the security.mac.seeotheruids.specificgid=XXX sysctl tunable. In the above example, the XXX should be replaced with the numeric group ID to be exempted.
security.mac.seeotheruids.primarygroup_enabled

is used to exempt specific

primary groups from this policy. When using this tunable, the
security.mac.seeotheruids.specificgid_enabled

may not be set.

MAC bsdextended Module

Module name: mac_bsdextended.ko

Kernel configuration line: options MAC_BSDEXTENDED

Boot option: mac_bsdextended_load="YES"

The mac_bsdextended(4) module enforces the file system firewall. This module's policy provides an extension to the standard file system permissions model, permitting an administrator to create a firewall-like ruleset to protect files, utilities, and directories in the file system hierarchy. When access to a file system object is attempted, the list of rules is iterated until either a matching rule is located or the end is reached. This behavior may be changed by the use of a sysctl(8) parameter, security.mac.bsdextended.firstmatch_enabled. Similar to other firewall modules in FreeBSD, a file containing access control rules can be created and read by the system at boot time using an rc.conf(5) variable.

The rule list may be entered using a utility, ugidfw(8), that has a syntax similar to that of ipfw(8). More tools can be written by using the functions in the libugidfw(3) library.

Extreme caution should be taken when working with this module; incorrect use could block access to certain parts of the file system

MAC ifoff Module

Module name: mac_ifoff.ko

Kernel configuration line: options MAC_IFOFF

Boot option: mac_ifoff_load="YES"

The mac_ifoff(4) module exists solely to disable network interfaces on the fly and keep network interfaces from being brought up during the initial system boot. It does not require any labels to be set up on the system, nor does it have a dependency on other MAC modules.

Most of the control is done through the sysctl tunables listed below.

security.mac.ifoff.lo_enabled will enable/disable all traffic on the loopback (lo(4)) interface.

security.mac.ifoff.bpfrecv_enabled will enable/disable all traffic on the Berkeley Packet Filter interface (bpf(4))

security.mac.ifoff.other_enabled will enable/disable traffic on all other interfaces.

You might also like