I republished a number of blog entries about auditing a few days ago, but there is another tool that carries the word audit in it: bart … formerly known as “basic audit reporting tool”. The name has disappeared from the man page. I originally published a blog entry about this feature almost 17 years ago. And the tool is still there.

The tool is small, but it is useful. For example, it can help you to solve the “I didn’t change a thing, and it stopped working!!” problem. Or it can help you to find out what’s part of your operating system and what’s part of your application when the documentation about it is lacking information about this rather important aspect of the system. Or you could use it to monitor changes over time in order to find out if a malevolent user is on your system. Or to gather information about changes when you know a malevolent user was on your system (of course you have to trust that the bart tool hasn’t been modified, booting the system from a known non-modified boot media may be a very good idea in such cases)

Okay, let’s assume you have finally configured a system to fulfill all your requirements. And you want to be able in the future to find out in a very fast way when something has changed. You can use the bart tool for this. bart works on the concept of manifests. A manifest contains important information about the files you have scanned with the bart tool. For example, checksums of file contents, but information about permissions and many other metainformation of this files as well.

The basic idea of the tool is: You compare manifests to find differences between an earlier state and the current state of the system. Or two past states to find out all the differences between them.

Using bart

So let’s create a place to store those manifests. An immutable ZFS filesystem may be a good idea. Or put the manifest somewhere else, where it can’t be deleted either by a malevolent or benevolent modifier.

root@testbed:~# zfs create -o retention.policy=mandatory -o mountpoint=/root/bart test/bart

Okay, now we create the manifest.

root@testbed:~/bart# bart create -R /etc > /root/bart/etc.control.manifest
root@testbed:~/bart# touch -R 0430180125 /root/bart/etc.control.manifest

Of course, you would use a much longer retention period in real life as you want to ensure that your original manifest can’t be deleted for a long time. On my testbed system, however, it would be a little bit impractical.

Let’s have a look into the manifest:

root@testbed:~# grep "nsswitch.conf" /root/bart/etc.control.manifest
/nsswitch.conf F 494 100644 owner@:read_data/write_data/append_data/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow,everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow 66879213 0 0 0c042d4ad4b320bedad4ed67030cc91fa7261c6ad3f0ace822f1ef9c4db20d5c

This information is the reference to find differences. Let’s introduce some changes into our system.

root@testbed:~/bart# touch /etc/thisisjustatest
root@testbed:~/bart# chmod 777 /etc/nsswitch.nis 
root@testbed:~/bart# echo "#just a test" >> /etc/nsswitch.nisplus

I will now create another manifest of the current state.

root@testbed:~/bart# bart create -R /etc > /root/bart/etc.check26042025.manifest

You can now compare both manifests with bart compare:

root@testbed:~/bart# bart compare /root/bart/etc.control.manifest /root/bart/etc.check26042025.manifest
/mnttab:
  mtime  control:680d2b6a  test:680d2cff
  contents  control:1d41cfc4e8192a413fe0e58a26a9c1ec984754d7c973b28ad1e5c52bb1f5c014  test:64a4a50dee29e3b4d7f7bb1b92fbc72490634a52e32e19fcd6380f4e284f4704
/nsswitch.nis:
  mode  control:100444  test:100777
  acl  control:owner@:read_data/read_xattr/write_xattr/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow,everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow  test:owner@:(read_data/write_data/append_data/read_xattr/write_xattr/execute/read_attributes/write_attributes/read_acl/write_acl/write_owner/synchronize:allow,group@:read_data/write_data/append_data/read_xattr/write_xattr/execute/read_attributes/write_attributes/read_acl/synchronize:allow,everyone@:read_data/write_data/append_data/read_xattr/write_xattr/execute/read_attributes/write_attributes/read_acl/synchronize):allow
/nsswitch.nisplus:
  add
/svc/repository.db:
  mtime  control:680d2a3e  test:680d2c96
  contents  control:bd497ca6e9eb51923e13b78aed23e12812ddd7dee4a131223a82b870b41152a2  test:c2779fa9b7668848f5a9c32d148e306453cfe99da34a809c3e642f1fd7988112
/thisisjustatest:
  add

The comparison now shows that we added two files (nisplus isn’t a part of Solaris 11 any longer; however, I used that file in the original Solaris 10-based blog entry), one file with changed permissions, and other files were changed by the system between both manifests.

Applicationectomy

I used this tool a few times for an applicationectomy to transplant an application from one system to another system. I installed a system in a temporary LDOM as close as possible to the patch level of the application donor system. I installed any known additional packages afterwards. Finally I compared this LDOM with the application donor system with bart and filtered in a first step for additions:

root@testbed:~/bart# bart compare -p  /root/bart/etc.control.manifest /root/bart/etc.check26042025.manifest | grep "add" 
/nsswitch.nisplus add 
/thisisjustatest add

Of course, the whole process was much more complex and much more iterative. And I used a number of rules to ignore certain changes. But I knew where I had to start.

Want to learn more ?

docs.oracle.com - Verifying File Integrity by Using BART