Under Construction
Adding File Definitions
In the previous examples, the attributes for the data record to be added were determined from the specified file. However, it is also possible to store the entire data record in a definition file and then add this data record to the TSD. In this case, attributes are not determined from the file for which the data record is being added. The attributes are adopted exactly as they appear in the definition file.
This can be very useful in a number of situations:
- The attributes, including hash value and signature, are already known, e.g. from another system or via a fileset or backup.
- Individual data records can be restored even if the private key is not available.
- Backup and restore of individual data records is thus easily possible.
As an example, consider the record for the /usr/bin/ls command. It has been accidentally deleted:
# trustchk -d /usr/bin/ls
#
Since /usr/bin/ls is a file associated with the AIX operating system, there is no way to calculate the original signature yourself. This would require the private key file used by IBM. However, this is not provided by IBM. This would also make the Trusted Execution System vulnerable to tampering. However, the correct TSD entry for /usr/bin/ls can easily be determined on another AIX system with the same version. To do so, simply run the command “trustchk -q /usr/bin/ls” on that system:
other # trustchk -q /usr/bin/ls
/usr/bin/ls:
owner = bin
group = bin
mode = 555
type = FILE
hardlinks =
symlinks =
size = 29389
cert_tag = 49424d4149583a30344232302d30334233303a324b3a41
signature = 20e9e76eae8cad24dd57a1076f4b4f08acfdd0984960c109cddc2e5d2f3696f4404515da159fa33aedae4d7af7416a30e9d1fabe1afd6c069e42bd582304d1b2dc7f397ac93f29fd65b85f0067be46b36f09edc9ce94b43159ae79ac9ffb280969a6ece7393e07e549fc82c4d746e8c813e6aba30e398aa33381961a53b8e2db895932890caa7fdf353f8a2380dbdb095bdfe2a02d2ce38ba6a4d4dde203ab65c75727f675907756c0fc185613956b0eeef2adadb6881998e68183d77c9400455972c012393a06738f4ea178d4f46cdd5d6655c4343b0386140a4afe51335ef0e1de287637bebe82cca91b23293f2c91292b3f1bb62296b756708c46ef230940
hash_value = df389b0e52e59ea8bee03e511d10efe6f86625578f9c8d3347b5f70b45b33da9
minslabel =
maxslabel =
intlabel =
accessauths = aix.fs.object.list
innateprivs = PV_DAC_R,PV_DAC_X
inheritprivs =
authprivs =
secflags = FSF_EPS
t_innateprivs = PV_MAC_R,PV_MIC
other #
The output already has the correct format for the definition file. We therefore redirect the output to a file named ls.def:
other # trustchk -q /usr/bin/ls >ls.def
other #
We then copy the resulting definition file to the system where the entry is missing (accidentally deleted). Then the TSD entry can be easily restored on this system by specifying the definition file with the additional “-f” option after the “-a” option:
# trustchk -a -f ls.def
#
Note: There is no verification at this point as to whether the entry is correct!
A check using “trustchk -q” shows that the entry is present again and matches the entry on the other system:
# trustchk -q /usr/bin/ls
/usr/bin/ls:
owner = bin
group = bin
mode = 555
type = FILE
hardlinks =
symlinks =
size = 29389
cert_tag = 49424d4149583a30344232302d30334233303a324b3a41
signature = 20e9e76eae8cad24dd57a1076f4b4f08acfdd0984960c109cddc2e5d2f3696f4404515da159fa33aedae4d7af7416a30e9d1fabe1afd6c069e42bd582304d1b2dc7f397ac93f29fd65b85f0067be46b36f09edc9ce94b43159ae79ac9ffb280969a6ece7393e07e549fc82c4d746e8c813e6aba30e398aa33381961a53b8e2db895932890caa7fdf353f8a2380dbdb095bdfe2a02d2ce38ba6a4d4dde203ab65c75727f675907756c0fc185613956b0eeef2adadb6881998e68183d77c9400455972c012393a06738f4ea178d4f46cdd5d6655c4343b0386140a4afe51335ef0e1de287637bebe82cca91b23293f2c91292b3f1bb62296b756708c46ef230940
hash_value = df389b0e52e59ea8bee03e511d10efe6f86625578f9c8d3347b5f70b45b33da9
minslabel =
maxslabel =
intlabel =
accessauths = aix.fs.object.list
innateprivs = PV_DAC_R,PV_DAC_X
inheritprivs =
authprivs =
secflags = FSF_EPS
t_innateprivs = PV_MAC_R,PV_MIC
#
You should immediately check whether the file /usr/bin/ls matches the TSD entry:
# trustchk -n /usr/bin/ls
#