This document discusses various security concepts in FreeBSD including file system protections like flags, access control lists, kernel security levels, jails, and techniques to harden the operating system like write xor execute (W^X) and cryptography. It provides details on file flags like immutable, append-only, and nodump and how they can be used to secure files. It also explains how to create and manage jails to isolate processes and provides an overview of tools to help administer jails.

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

2. Security Types

3. Encryption and Decryption. Symmetric and Asymmetric. Security Topics

4. FreeBSD Security Categories

5. 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

6. 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.

7. 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.

8. 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

9. 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)

10. 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)

11. 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)

12. 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)

13. 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)

14. 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)

15. 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)

16. 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)

17. 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

18. 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

19. /etc/fstab file Tagging the superblock directly Enable ACLs

20. /etc/fstab Enable ACL Option for /home directory

22. unmount idle filesystemwith the following steps

23. umount it.

24. run tunefs -a /home.ACLs in the superblock

25. % 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

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

28. In the shell, sysctlkern.securelevel=2

29. Secure the kernel permanently.

30. In /etc/sysctl.conf, sysctlkern.securelevel=2Kernel

32. chroot Jail User Process Control

33. 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

34. 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.

35. 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

36. 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

37. # 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

38. 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

39. 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

40. 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

41. /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

42. Jail Configuration

44. using the jexecutility from outside the jail.Jail Starting & Stopping

45. 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

46. Fighting Buffer Overflows Cryptography. Inherent Protection

47. 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

48. 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)

50. Safety Liveness. … System Security Requirements

51. Policy (Access Rights)

53. desribes how to apply the policy Mechanism

55. Decision Making.

56. Policy-Kernel Interfacing.MAC Framework

57. Snort. Snorby. Intrusion Detection Common Ports

58. Questions

59. Thank you