Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Security Services Oracle Solaris 11 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. Using the Basic Audit Reporting Tool (Tasks)
Basic Audit Reporting Tool (Overview)
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. Network Services Authentication (Tasks)
17. Using Secure Shell (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)
You can run the bart command as a regular user, superuser, or a user who has assumed a role. If you run the bart command as a regular user, you are only able to catalog and monitor files that you have permission to access, such as files in your home directory. The advantage of becoming superuser when you run the bart command is that the manifests you create contain information about hidden and private files that you might want to monitor. If you need to catalog and monitor information about files that have restricted permissions, for example, the /etc/passwd or /etc/shadow file, run the bart command as superuser. For more information about using role-based access control, see Role-Based Access Control (Overview).
Running the bart command as superuser makes the output readable by anyone. This output might contain file names that are intended to be private. If you become superuser when you run the bart command, take appropriate measures to protect the output. For example, use options that generate output files with restrictive permissions.
Note - The procedures and examples in this chapter show the bart command run by superuser. Unless otherwise specified, running the bart command as superuser is optional.
|
You can create a manifest of a system immediately after an initial Oracle Solaris software installation. This type of manifest provides you with a baseline for comparing changes to the same system over time. Or, you can use this manifest to compare with the manifests for different systems. For example, if you take a snapshot of each system on your network, and then compare each test manifest with the control manifest, you can quickly determine what you need to do to synchronize the test system with the baseline configuration.
Before You Begin
To create a system manifest, you must be in 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. Note that –, when used with the -r option, 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.
Choose a meaningful name for the manifest. For example, use the system name and date that the manifest was created.
Example 6-1 Creating a Manifest That Lists Information About Every File on a System
If you run the bart create command without any options, information about every file that is installed on the system is cataloged. Use this type of manifest as a baseline when you are installing many systems from a central image. Or, use this type of manifest to run comparisons when you want to ensure that the installations are identical.
For example:
# bart create ! Version 1.1 ! HASH SHA256 ! Wednesday, September 07, 2011 (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 entries. Each manifest file entry is a single line, depending on the file type. For example, for each manifest 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, have the nonstandard characters quoted before being sorted.
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. 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 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
Creating a manifest for an individual subtree on a system is an efficient way to monitor changes to specific files, rather than the entire contents of a large directory. You can create a baseline manifest of a specific subtree on your system, then periodically create test manifests of the same subtree. Use the bart compare command to compare the control manifest with the test manifest. By using this option, you are able to efficiently monitor important file systems to determine whether any files have been compromised by an intruder.
By specifying a file name
Since creating a manifest that catalogs the entire system is more time-consuming, takes up more space, and is more costly, you might choose to use this option of the bart command when you want to only list information about a specific file or files on a system.
By using a rules file
You use a rules file to create custom manifests that list information about specific files and specific subtrees on a given system. You can also use a rules file to monitor specific file attributes. Using a rules file to create and compare manifests gives you the flexibility to specify multiple attributes for more than one file or subtree. Whereas, from the command line, you can only specify a global attribute definition that applies to all files for each manifest you create or report you generate.
Before You Begin
You must be in the root role.
By specifying a subtree:
# bart create -R root-directory
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
Use this procedure when you want to monitor file-level changes to the same system over time. This type of manifest can assist you in locating corrupted or unusual files, detecting security breaches, or in troubleshooting performance issues on a system.
Before You Begin
To create and compare manifests that include public objects, you must be in the root role.
# bart create -R /etc > control-manifest
# bart create -R /etc > test-manifest
# bart compare options control-manifest test-manifest > bart-report
Is the name of the rules file for this comparison. Using the -r option with the – means that the directives read from standard input.
Allows the user to set global IGNORE directives from the command line.
Is the programmatic mode that generates standard non-localized output for programmatic parsing.
Is the output from the bart create command for the control system.
Is the output from the bart create command of the test system.
Example 6-2 Comparing Manifests for the Same System Over Time
This example shows how to monitor changes that have occurred in the /etc directory between two points in time. This type of comparison enables you to quickly determine whether important files on the system have been compromised.
Create a control manifest.
# bart create -R /etc > system1.control.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 /.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 . . .
Create a test manifest when you want to monitor changes to the /etc directory.
# bart create -R /etc > system1.test.101011 Version 1.1 ! HASH SHA256 ! Monday, October 10, 2011 (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 control manifest with the test manifest.
# bart compare system1.control.090711 system1.test.101011 /security/audit_class mtime 4f272f59
The preceding output indicates that the modification time on the audit_class file has changed since the control manifest was created. This report can be used to investigate whether ownership, date, content, or any other file attributes have changed. Having this type of information readily available can assist you in tracking down who might have tampered with the file and when the change might have occurred.
You can run system to system comparisons, thereby enabling you to quickly determine whether there are any file-level differences between a baseline system and the other systems. For example, if you have installed a particular version of the Oracle Solaris software on a baseline system, and you want to know whether other systems have identical packages installed, you can create manifests for those systems and then compare the test manifests with the control manifest. This type of comparison lists any discrepancies in the file contents for each test system that you compare with the control system.
Before You Begin
To compare system manifests, you must be in the root role.
# bart create options > control-manifest
# bart create options > test1-manifest
Choose a distinct and meaningful name for the test manifest.
For example:
# cp control-manifest /net/test-server/bart/manifests
If the test system is not an NFS-mounted system, use FTP or some other reliable means to copy the control manifest to the test system.
# bart compare control-manifest test1-manifest > test1.report
Use the same bart options for each test system.
Example 6-3 Comparing Manifests From Different Systems With the Manifest of a Control System
This example describes how to monitor changes to the contents of the /usr/bin directory by comparing a control manifest with a test manifest from a different system.
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 a test 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 ...
When you want to compare manifests, copy the manifests to the same location.
# cp control-manifest /net/system2.central/bart/manifests
Compare the control manifest with the test manifest.
# bart compare control-manifest system2.test > system2.report /su: gid control:3 test:1 /ypcat: mtime control:3fd72511 test:3fd9eb23
The previous 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 can be helpful in determining whether a different version of the software was installed on the test system or if possibly someone has tampered with the file.
This procedure is optional and explains how to customize a BART report by specifying file attributes from the command line. If you create a baseline manifest that lists information about all the files or specific on your system, you can run the bart compare command, specifying different attributes, whenever you need to monitor changes to a particular directory, subdirectory, file or files. You can run different types of comparisons for the same manifests by specifying different file attributes from the command line.
Before You Begin
You must be in the root role.
Prepare the test manifest identically to the control manifest.
For example:
# bart compare -i dirmtime,lnmtime,mtime control-manifest.121503 \ test-manifest.010504 > bart.report.010504
Note that a comma separates each attribute you specify in the command-line syntax.
This procedure is also optional and explains how to customize a BART report by using a rules file as input to the bart compare command. By using a rules file, you can customize a BART report, which allows you the flexibility of specifying multiple attributes for more than one file or subtree. You can run different comparisons for the same manifests by using different rules files.
Before You Begin
You must be in the root role.
# bart create -r rules-file > control-manifest
# bart create -r rules-file > test-manifest
# bart compare -r rules-file control-manifest test-manifest > bart.report
Example 6-4 Customizing a BART Report by Using a Rules File
The following rules file includes directives for both the bart create and the bart compare commands. The rules file directs the bart create command to list information about the contents of the /usr/bin directory. In addition, the rules file directs the bart compare command to track 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 by using the rules file you created.
# bart create -r bartrules.txt > usr_bin.control-manifest.121003
Create a test manifest whenever you want to monitor changes to the /usr/bin directory.
# bart create -r bartrules.txt > usr_bin.test-manifest.121103
Compare the manifests by using the same rules file.
# bart compare -r bartrules.txt usr_bin.control-manifest \ usr_bin.test-manifest
Examine the output of the bart compare command.
/usr/bin/gunzip: add /usr/bin/ypcat: delete
In the preceding output, the bart compare command reported a discrepancy in the /usr/bin directory. This output indicates that /usr/bin/ypcat file was deleted, and the /usr/bin/gunzip file was added.