Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Verifying File Integrity by Using BART (Tasks)
How to Create a Control Manifest
How to Compare Manifests for the Same System Over Time
How to Compare Manifests From Different Systems
How to Customize a BART Report by Specifying File Attributes
BART Manifests, Rules Files, and Reports (Reference)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Security Attributes in Oracle Solaris (Reference)
Part IV Cryptographic Services
11. Cryptographic Framework (Overview)
12. Cryptographic Framework (Tasks)
Part V Authentication Services and Secure Communication
14. Using Pluggable Authentication Modules
17. Using Simple Authentication and Security Layer
18. Network Services Authentication (Tasks)
19. Introduction to the Kerberos Service
20. Planning for the Kerberos Service
21. Configuring the Kerberos Service (Tasks)
22. Kerberos Error Messages and Troubleshooting
23. Administering Kerberos Principals and Policies (Tasks)
24. Using Kerberos Applications (Tasks)
25. The Kerberos Service (Reference)
The bart command is used to create and compare manifests. Any user can run this command. However, users can only catalog and monitor files that they have permission to access. So, users and most roles can usefully catalog the files in their home directory, but the root account can catalog all files, including system files.
BART manifests and reports are readable by anyone. If BART output might contain sensitive information, take appropriate measures to protect the output. For example, use options that generate output files with restrictive permissions or place output files in a protected directory.
|
This procedure explains how to create a baseline manifest for your system. Use this type of manifest when you are installing many systems from a central image. Or, use this type of manifest to run comparisons when you want to verify that the installations are identical. For more information about baseline manifests, see BART Manifest. To understand the format conventions, see Example 6-1.
Note - Do not attempt to catalog networked file systems. Using BART to monitor networked file systems consumes large resources to generate manifests of little value.
Before You Begin
To create a control manifest of your system, you must assume the root role.
# bart create options > control-manifest
Specifies the root directory for the manifest. All paths specified by the rules are interpreted relative to this directory. All paths reported in the manifest are relative to this directory.
Accepts a list of individual files to be cataloged, either on the command line or read from standard input.
Is the name of the rules file for this manifest. A - argument reads the rules file from standard input.
Turns off content signatures for all regular files in the file list. This option can be used to improve performance. Or, you can use this option if the contents of the file list are expected to change, as in the case of system log files.
For an explanation of the format, see Example 6-1.
One way to protect system manifests is to place them in a directory that only the root account can access.
# mkdir /var/adm/log/bartlogs # chmod 700 /var/adm/log/bartlogs # mv control-manifest /var/adm/log/bartlogs
Choose a meaningful name for the manifest. For example, use the system name and date that the manifest was created, as in mach1-120312.
Example 6-1 Explanation of the BART Manifest Format
In this example, an explanation of the manifest format follows the sample output.
# bart create ! Version 1.1 ! HASH SHA256 ! Friday, September 07, 2012 (22:22:27) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 1024 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3ebc418eb5be3729ffe7e54053be2d33ee884205502c81ae9689cd8cca5b0090 0 0 . . . /zone D 512 40755 user::rwx group::r-x,mask:r-x,other:r-x 3f81e892 154de3e7bdfd0d57a074c9fae0896a9e2e04bebfe5e872d273b063319e57f334 0 0 . . .
Each manifest consists of a header and file entries. Each file entry is a single line, depending on the file type. For example, for each file entry in the preceding output, type F specifies a file and type D specifies a directory. Also listed is information about size, content, user ID, group ID, and permissions. File entries in the output are sorted by the encoded versions of the file names to correctly handle special characters. All entries are sorted in ascending order by file name. All nonstandard file names, such as those that contain embedded newline or tab characters, quote the nonstandard characters before sorting.
Lines that begin with ! supply metadata about the manifest. The manifest version line indicates the manifest specification version. The hash line indicates the hash mechanism that was used. For more information about the SHA256 hash that is used as a checksum, see the sha2(3EXT) man page.
The date line shows the date on which the manifest was created, in date form. See the date(1) man page. Some lines are ignored by the manifest comparison tool. Ignored lines include metadata, blank lines, lines that consist only of white space, and comments that begin with #.
You can customize a manifest in one of the following ways:
By specifying a subtree
Specifying an individual subtree is an efficient way to monitor changes to selected, important files, such as all files in the /etc directory.
By specifying a file name
Specifying a file name is an efficient way of monitoring particularly sensitive files, such as the files that configure and run a database application.
By using a rules file
By using a rules file to create and compare manifests gives you the flexibility to specify multiple attributes for more than one file or subtree. From the command line, you can specify a global attribute definition that applies to all files in a manifest or report. From a rules file, you can specify attributes that do not apply globally.
Before You Begin
You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.
By specifying a subtree:
# bart create -R subtree
By specifying a file name or file names:
# bart create -I filename...
For example:
# bart create -I /etc/system /etc/passwd /etc/shadow
By using a rules file:
# bart create -r rules-file
For an example, see Step 3 in How to Create a Control Manifest.
Tip - If you used a rules file, save the rules file with the manifest. For a useful comparison, you must run the comparison with the rules file.
By comparing manifests over time, you can locate corrupted or unusual files, detect security breaches, and troubleshoot performance issues on a system.
Before You Begin
To create and compare manifests that include system files, you must assume the root role.
# bart create -R /etc > control-manifest
For an example, see Step 3 in How to Create a Control Manifest.
# bart create -R /etc > test-manifest
# mv test-manifest /var/adm/log/bartlogs
Use the same command-line options and rules file to compare the manifests that you used to create them.
# bart compare options control-manifest test-manifest > bart-report
Example 6-2 Tracking File Changes for the Same System Over Time
This example shows how to track the changes in the /etc directory over time. This type of comparison enables you to locate important files on the system that have been compromised.
Create a control manifest.
# cd /var/adm/logs/manifests # bart create -R /etc > system1.control.090712 ! Version 1.1 ! HASH SHA256 ! Friday, September 07, 2012 (11:11:17) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /.cpr_config F 2236 100644 owner@:read_data/write_data/append_data/read_xattr/wr ite_xattr/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchr onize:allow,group@:read_data/read_xattr/read_attributes/read_acl/synchronize:all ow,everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow 4e271c59 0 0 3ebc418eb5be3729ffe7e54053be2d33ee884205502c81ae9689cd8cca5b0090 /.login F 1429 100644 owner@:read_data/write_data/append_data/read_xattr/write_x attr/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchronize :allow,group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow,ev eryone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow 4bf9d6d7 0 3 ff6251a473a53de68ce8b4036d0f569838cff107caf1dd9fd04701c48f09242e . . .
Later, create a test manifest by using the same command-line options.
# bart create -R /etc > system1.test.101012 Version 1.1 ! HASH SHA256 ! Wednesday, October 10, 2012 (10:10:17) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /.cpr_config F 2236 100644 owner@:read_data/write_data/append_data/read_xattr/wr ite_xattr/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchr onize:allow,group@:read_data/read_xattr/read_attributes/read_acl/synchronize:all ow,everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow 4e271c59 0 0 3ebc418eb5be3729ffe7e54053be2d33ee884205502c81ae9689cd8cca5b0090 . . .
Compare the manifests.
# bart compare system1.control.090712 system1.test.101012 /security/audit_class mtime 4f272f59
The output indicates that the modification time on the audit_class file has changed since the control manifest was created. If this change is unexpected, you can investigate further.
By comparing manifests from different systems, you can determine if the systems are installed identically or have been upgraded in synch. For example, if you customized your systems to a particular security target, this comparison finds any discrepancies between the manifest that represents your security target, and the manifests from the other systems.
Before You Begin
To compare system manifests, you must assume the root role.
# bart create options > control-manifest
For the options, see the bart(1M) man page.
For an example, see Step 3 in How to Create a Control Manifest.
# bart create options > test1-manifest
For example:
# cp control-manifest /net/test-server/var/adm/logs/bartlogs
If the test system is not an NFS-mounted system, use sftp or another reliable means to copy the manifests to a central location.
# bart compare control-manifest test1-manifest > test1.report
Example 6-3 Identifying a Suspect File in the /usr/bin Directory
This example compares the contents of the /usr/bin directory on two systems.
Create a control manifest.
# bart create -R /usr/bin > control-manifest.090711 ! Version 1.1 ! HASH SHA256 ! Wednesday, September 07, 2011 (11:11:17) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /2to3 F 105 100555 owner@:read_data/read_xattr/write_xattr/execute/read_attribut es/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:read _data/read_xattr/execute/read_attributes/read_acl/synchronize:allow,everyone@:re ad_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4bf9d261 0 2 154de3e7bdfd0d57a074c9fae0896a9e2e04bebfe5e872d273b063319e57f334 /7z F 509220 100555 owner@:read_data/read_xattr/write_xattr/execute/read_attribu tes/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:rea d_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow,everyone@:r ead_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4dadc48a 0 2 3ecd418eb5be3729ffe7e54053be2d33ee884205502c81ae9689cd8cca5b0090 ...
Create an identical manifest for each system that you want to compare with the control system.
# bart create -R /usr/bin > system2-manifest.101011 ! Version 1.1 ! HASH SHA256 ! Monday, October 10, 2011 (10:10:22) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /2to3 F 105 100555 owner@:read_data/read_xattr/write_xattr/execute/read_attribut es/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:read _data/read_xattr/execute/read_attributes/read_acl/synchronize:allow,everyone@:re ad_data/read_xattr/execute/read_attributes/read_acl/synchronize:allow 4bf9d261 0 2 154de3e7bdfd0d57a074c9fae0896a9e2e04bebfe5e872d273b063319e57f334 ...
Copy the manifests to the same location.
# cp control-manifest.090711 /net/system2.central/bart/manifests
Compare the manifests.
# bart compare control-manifest.090711 system2.test.101011 > system2.report /su: gid control:3 test:1 /ypcat: mtime control:3fd72511 test:3fd9eb23
The output indicates that the group ID of the su file in the /usr/bin directory is not the same as that of the control system. This information might indicate that a different version of the software was installed on the test system. Because the GID is changed, the more likely reason is that someone has tampered with the file.
This procedure is useful to filter the output from existing manifests for specific file attributes.
Before You Begin
You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.
For example:
# bart compare -i lnmtime,mtime control-manifest.121511 \ test-manifest.010512 > bart.report.010512
Use a comma in the command-line syntax to separate each file attribute.
By using a rules file, you can customize a BART manifest for particular files and file attributes of interest. By using different rules files on default BART manifests, you can run different comparisons for the same manifests.
Before You Begin
You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.
# bart create -r myrules1-file > control-manifest
For an example, see Step 3 in How to Create a Control Manifest.
# bart create -r myrules1-file > test-manifest
# bart compare -r myrules1-file control-manifest test-manifest > bart.report
Example 6-4 Using a Rules File to Customize BART Manifests and the Comparison Report
The following rules file directs the bart create command to list all attributes of the files in the /usr/bin directory. In addition, the rules file directs the bart compare command to report only size and content changes in the same directory.
# Check size and content changes in the /usr/bin directory. # This rules file only checks size and content changes. # See rules file example. IGNORE all CHECK size contents /usr/bin
Create a control manifest with the rules file that you created.
# bart create -r usrbinrules.txt > usr_bin.control-manifest.121011
Prepare an identical manifest whenever you want to monitor changes to the /usr/bin directory.
# bart create -r usrbinrules.txt > usr_bin.test-manifest.121111
Compare the manifests by using the same rules file.
# bart compare -r usrbinrules.txt usr_bin.control-manifest.121011 \ usr_bin.test-manifest.121111
Examine the output of the bart compare command.
/usr/bin/gunzip: add /usr/bin/ypcat: delete
The preceding output indicates that the /usr/bin/ypcat file was deleted, and the /usr/bin/gunzip file was added.