Lecture 4 FreeBSD Security + FreeBSD Jails + MAC Security Framework

Mohammed Farragmfarrag@freebsd.orghttp://wiki.freebsd.org/MohammedFarrag

Security Types

Encryption and Decryption.
Symmetric and Asymmetric.
Security Topics

FreeBSD Security Categories

UFS:
implement special filesystem flags on files.
flags enforce the same behavior for all users.
kernel is responsible for enforcing these controls, depending on your kernel securelevel.
Filesystem Protections

UFS2:
use Access Control Lists producing fine-grained control over permissions.
Different users can be given different sets of permissions without relying on traditional Unix groups.

Turn off the flag
Specifying 0 in place of a flag name will turn off all the flags on a file. It's an inelegant little shortcut, but it works. For example, chflags 0foo will turn off all the flags on the file foo.

Use –o option of ls command
Example: /var/log
-rw------- 1 root wheel sappnd 1862 Sep 30 22:39 auth.log
-rw------- 1 root wheel sappnd 38374 Sep 30 22:45 cron
-rw------- 1 root wheel nodump 3157 Sep 30 03:06 dmesg.today
-rw-r--r-- 1 root wheel sappnd 28056 Sep 30 22:39 lastlog
-rw-r--r-- 1 root wheel - 0 Jun 4 21:57 lpd-errs
-rw-r----- 1 root wheel sappnd 2160 Sep 30 03:06 maillog
-rw-r--r-- 1 root wheel sappnd 15547 Sep 30 22:47 messages
-rw-r----- 1 root mail sappnd 628 Sep 30 03:06 sendmail.st
-rw-r----- 1 root mail schg 3455 Sep 29 22:00 sendmail.st.0
-rw-r----- 1 root mail schg 5543 Jun 4 21:57 sendmail.st.1
View active flags on a file

schg, is derived from "system change," it is universally referred to as the "immutable" flag. When the system immutable flag is set on a file, nothing can modify any part of it. Its metadata (modification times, permissions, owner, group, and so on) cannot be changed, nor can its contents. It cannot be renamed, unlinked (i.e., deleted), or moved, either.
Only root can unset at zero kernel security level.
System immutable flag (schg)

The user immutable flag is a kinder, gentler immutable flag that is not affected by the kernel securelevel.
Users can set and unset this on their own files and directories, just as root can.
Unlike the system immutable flag, this one can be unset at any time.
In order to be able to set this flag, you must be either the file's owner or root.
A user with write access via Unix groups or ACLs, for example, still cannot set this flag.
User immutable flag (uchg)

Normally all files in a filesystem are backed up when the dump(8) program runs. The nodump flag tells the backup system not to include the given file in the dumps.
To tell dump to honor the nodump flag, specify -h on the dump command line.
If you want files to be omitted from backups entirely (i.e., not even included on full dumps), then you need to specify -h 0 on the command line.
Nodump flag (nodump)

The append-only flag prevents files from being modified, much like the immutable flag, with one exception: data can be appended at the end of the file. The archetypal use of the append-only flag is for logfiles on secured servers or perhaps for root's .history file to help catch unwary hackers (see "Candidates for append-only," later in this chapter).
System append-only flag (sappnd)

The user append-only flag performs exactly as the system append-only flag described above. The only difference is that this flag can be unset by both the owner and root at any time, regardless of the kernel securelevel.
User append-only flag (uappnd)

This flag is a little weaker than the schg flag. It simply prevents the deletion of a file. It is arguably most useful in its "user" version, uunlnk.
It does not prevent truncation of the file or modification of its contents, its permissions, or any other aspect. It merely prevents the file from being removed.
Like other "system" flags, it can only be set by root, and it cannot be unset when the kernel security level is greater than 0.
This flag exists only in FreeBSD
System no unlink flag (sunlnk)

This flag allows a user to indicate that a file may not be deleted, regardless of the actual Unix permissions on its parent directory. Normally, if a user has permissions (through user, group, or ACLs) on the parent directory, she can delete any file in the directory—even files she does not own.
That's because, in Unix filesystems such as UFS, the permission for deleting a file is a function of modifying the directory, not the file itself.
User no unlink flag (uunlnk)

Opaque flags are used on directories or files that are involved in unionfs mounts. Union mounts allow one directory or filesystem to be mounted over the top of another directory while retaining visibility into the underlying directory. Thus, when you look in the top-level directory, you see the union of the two directories. A file that exists in one place but not the other (XOR) will be visible. If there are files or directories of the same name in both places, the "uppermost" one is the one that is accessible.
Opaque flag (opaque)

When a directory is marked opaque with the opaque flag, it only shows files that actually exist in its level. That is, it makes the union mount act like a regular mount; files in the corresponding directory of a lower layer will be invisible.
Opaque flag (opaque) – cont’d

The find command understands flags if you give it the -flags argument.
For instance, this command finds all files that have the uunlnk flag set in user paco's home directory:
find /home/paco -flags +uunlnk -print.
File Flags Searching

/etc/fstab file
Tagging the superblock directly
Enable ACLs

/etc/fstab
Enable ACL Option for /home directory

Preferable.
Can be used in two ways
Single User Mode.
unmount idle filesystemwith the following steps
umount it.
run tunefs -a /home.
ACLs in the superblock

% setfacl -b book.pdf # Erase any existing ACLs
# Add ahmed’s access
% setfacl -m u:ahmed:rw book.pdf
# Nobody else gets any permission at all
setfacl -m o:: book.pdf
Setting ACLs for Files
File name
User/Group/Others
User/Group name
Access Rights

getfacl book.pdf
#file:book.pdf
#owner:1001
#group:100
user::rw- user:ahmed:rw-
mask::rw-
other::---
Viewing ACLs for Files

We can modify the kernel security architecture using Sysctl’s.
We have 5 levels of kernel security (-1 .. 3).
Enable Kernel Security:
Secure the kernel till the next boot
In the shell, sysctlkern.securelevel=2
Secure the kernel permanently.
In /etc/sysctl.conf, sysctlkern.securelevel=2
Kernel

chroot
Jail
User Process Control

The principles behind chroot are simple.
A process running in a chrooted environment sees a normal filesystem, but it in fact has a virtual root directory. The goal is to prevent the process from accessing files outside its sandbox.
chroot

If ntpd runs in a chrooted environment, for example, and an exploit is discovered that causes it to overwrite a file, files in the real filesystem should be protected. The daemon perceives a / directory and will write relative to that directory, but on the real filesystem, the directory is something like /var/ntpd, and the daemon cannot actually reach the real / directory.

Jails expand this model by virtualizing not only access to the file system, but also the set of users, the networking subsystem of the FreeBSD kernel and a few other things.
FreeBSD Jail

A directory subtree -- the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree.
A hostname -- the hostname which will be used within the jail. Jails are mainly used for hosting network services, therefore having a descriptive hostname for each jail can really help the system administrator.
An IP address -- this will be assigned to the jail and cannot be changed in any way during the jail's life span.
A command -- the path name of an executable to run inside the jail.
Jail Characteristics

# setenv D /here/is/the/jail
# mkdir -p $D
# cd /usr/src
# make buildworld
# make installworld DESTDIR=$D
# make distribution DESTDIR=$D
# mount -t devfsdevfs $D/dev
Creating Jails

Selecting a location for a jail is the best starting point. This is where the jail will physically reside within the file system of the jail's host.
A good choice can be /usr/jail/jailname, where jailname is the hostname identifying the jail.
# mkdir -p $D

The distribution target for make installs every needed configuration file. In simple words, it installs every installable file of /usr/src/etc/ to the /etc directory of the jail environment: $D/etc/.
make distribution DESTDIR=$D

Mounting the devfs file system inside a jail is not required.
It is very important to control access to devices from inside a jail, as improper settings could permit an attacker to do nasty things in the jail. Control over devfs(8) is managed through rulesets which are described in the devfs(8) and devfs.conf(5) manual pages.
# mount -t devfsdevfs $D/dev

/etc/rc.conf since it will replicate the startup sequence of a real FreeBSD system. For a service jail, it depends on the service or application that will run within the jail.
Jail Enabling

Jail Configuration

From Host System
# /etc/rc.d/jail start www
# /etc/rc.d/jail stop www
The best way to shut down a jail is:
# sh /etc/rc.shutdown from inside the jail.
using the jexecutility from outside the jail.
Jail Starting & Stopping

Among the many third-party utilities for jail administration, one of the most complete and useful is sysutils/jailutils. It is a set of small applications that contribute to jail management. Please refer to its web page for more information.
Jail High-level administrative tools

Fighting Buffer Overflows
Cryptography.
Inherent Protection

The goal of W^X is to make a program crash if it attempts to write to an execute-only page or execute code on a write-only page. The kernel and the loader try to make sure that a program's instructions are always allocated on pages marked executable, and data (e.g., the program's stack and heap) is always allocated to pages that are writable but not executable

maxusers
make it 0 to turn control to physical RAM.
Increasing Maximum Values.
For example, kern.ipc.somaxconn.
Network Buffering
For example, net.inet.tcp.sendspace
Optimizations (OS Tuning)

Safety
Liveness.
…
System Security Requirements

Policy (Access Rights)

desribes how to apply the policy
Mechanism

Introduction (Time-Money Overview).
Framework as intermediate layer between policy writers and kernel developers.
Framework Capabilities.
Policy Composition.
Decision Making.
Policy-Kernel Interfacing.
MAC Framework

Snort.
Snorby.
Intrusion Detection Common Ports

Questions

Thank you

Lecture 4 FreeBSD Security + FreeBSD Jails + MAC Security Framework

by Mohammed Farrag on Jul 24, 2011

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 74

Statistics

Lecture 4 FreeBSD Security + FreeBSD Jails + MAC Security Framework Presentation Transcript

http://mj89sp3sau2k7lj1eg3k40hkeppguj6j-a-sites-opensocial.googleusercontent.com	72
http://127.0.0.1:800	2