As promised, I post now the last part of this blog series about TE (Trusted Execution). See below the links to my blogs in this series:
part1: https://community.ibm.com/community/user/power/blogs/christian-sonnemans1/2024/02/08/aix-and-te-sec-part1
part2: https://community.ibm.com/community/user/power/blogs/christian-sonnemans1/2024/02/22/aix-and-te-trusted-execution-an-underestimated-sec
part3: https://community.ibm.com/community/user/power/blogs/christian-sonnemans1/2024/03/21/aix-and-te-trusted-execution-an-underestimated-sec
But first I like to tell something about a recent discovery I did. This discovery is about two items that I also discussed in part-3 of this blog series.
The first items about the /etc/nscontrol.conf.
However still undocumented yet, IBM guaranteed that this is supported upon the following versions:
From 7100-05-11-2246, 7200-05-05-2245, 7300-00-03-2246 and 7300-01 and in future releases.
You can now add another stanza into the /etc/nscontrol.conf
See example below:
btsddat:
secorder = LDAP
databasename = 730201_2346_tsd_v5
Big advantage is that the second item the AIX command: tetoldif does now read this stanza and can generate the complete ldif file for uploading it to ldap in one single command:
tetoldif -d cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl > /home/user/TE/te.ldif
So if the /etc/nscontrol.conf is configured with all the tree database stanza’s see example below than you get one ldif file that contains all the information to upload to ldap.
Example for /etc/nscontol.conf containing all the tree database items:
# TE databases
tsddat:
secorder = LDAP
databasename = 730201_2346_tsd_v5
libtsddat:
secorder = LDAP
databasename = 730201_2346_tsd_v5
tepolicies:
secorder = LDAP
databasename = 730201_2346_tepol_v5
This make maintaining it to Ldap a bit easier.
Caveat:
man pages for tetoldif are not updated yet!
Also tools like chsec lssec cannot handle this stanza for /etc/nscontrol.conf yet.
The next part I like to discuss when TE and it’s databases tsd.dat and libtsd.dat needs to be maintained and best practices for this.
Maybe you can answer this question already if you read my second blog, but for short keep in mind that each time you add, remove a AIX fileset the tsd.dat and / or the libtsd.dat databases are changed, the same case for applying Efixes.
And if you add or modify own singed script executables and libraries, the tsd.dat and / or the libtsd.dat database files are changed.
If you do not store your database on a ldap server you have to repeat this for every Lpar, in your environment, and obviously you will script this. Better solution is storing the them on an Ldap server.
See below the tasks you should do on a local lpar (not storing the database on Ldap)
1. Disable TE trustchk -p te=off
2. Make a copy of the local /etc/security/tsd/tsd.dat and libtsd.dat.
3. Update / remove the filesets and or own scripts executables and libraries.
4. Test after removal / updates if the Lpar is in a correct state? (trustchk -n all)
5. Decide to rollback or fix foreward.
6. Enable TE again trustchk -p te=on
7. Repeat this for every updated Lpar, where you would like to enable TE runtime.
With storing the TE databases for the same (groups) of Lpars, for example the same Oracle servers on the same TL and SP en efix level you can do:
1. On a golden image Lpar disable TE (trustchk -p te=off
2. cp /etc/security/tsd/ldap/tsd.dat /etc/security/tsd ß only if you reuse the previous Ldap data.
3. cp /etc/security/tsd/ldap/lib.tsd.dat /etc/security/tsd/lib/lib.tsd.dat ß only if you reuse the previous Ldap data
4. edit /etc/nscontrol.conf and switch to local databases (for all TE stanza’s) secorder = files
5. check Lpar consistency before you start (trustchk -n all)
6. update the Lpar apply filesets Efixes or own files to the tsd.dat or lib.tsd.dat
7. check Lpar consistency before you start (trustchk -n all)
8. edit /etc/nscontrol.conf with new database names to store on Ldap.
9. Upload the new database to ldap (tetoldif + upload script).
10. At this moment the new database are available for all the Lpar’s via Ldap.
As you notice some extra step’s but you can prepare this on your golden image Lpar, and you only have to do this once!
After this on the upgraded Lpar’s that have the same level and filesets you now only have to do the following:
Initial steps on other Lpars (only on new Lpars added to TE-ldap):
1. Distribute the certificate for the you own singed items added to TE. And store this certificate in /etc/security/certificates
2. Distribute or update the /etc/security/ldap/ldap.cfg with the base DN’s for TE see below:
tsddatbasedn:ou=Tsddat,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
tepoliciesbasedn:ou=Tepolicies,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
libtsdbasedn:ou=libtsddat,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
After this run a script of Ansible tasks to achieve the following on each Lpar:
Upgrade the Lpar to with a new TL, SP, or Efix (same steps that you applied on de golden image).
Then take the following steps for adjusting TE to the right Ldap database:
1. Stop the runtime TE (trustchk -p te=off)
2. Change the /etc/nscontrol.conf to local databases with chsec or with a sed script (chsec cannot handle at this moment the libtsddat stanza)
3. After this chsec or modify the /etc/nscontrol.conf to the new Ldap database.
4. Verify with trustchk -n all, for constancy
5. Enable TE (trustchk -p te=on).
This all can be automated, and we now using NIM script to do this job for us, and for applying TL’s SP’s and kernel efixes we use LU (Live Update) to do this for us, part of the post script is setting the right TE – Ldap databases.
Examples for naming conventions on LDAP:
If you look at my samples for the nscontrol.conf you can see that I use a kind of naming convention for the stored databases see below part of the /etc/nscontrol.conf again:
tsddat:
secorder = LDAP
databasename = 730201_2346_tsd_v5
libtsddat:
secorder = LDAP
databasename = 730201_2346_tsd_v5
For the tsd.dat and the lib.tsd.dat files the database names must be the same otherwise you get a mismatch, and a trustchk -n all will fail.
In the above example you see that the first part of the database name is the AIX OS level, second is the build date, and last part is a version number.
Reason for this method we use is that we now can have for every update logical name with a version number. This makes it easier to read and makes it possible to have several versions of the same level. This is necessary because you can have for instance several Efixes and or script changes for our own maintained files.
Note: This is just an example of a name convention you can do but keep it simple so that you can easily find were every database belongs to.
Tip: if you are updating you TE - Ldap database from an older to new version and you liked to “save” your own signed items stored on Ldap you can do the following before you start:
Run the following one liner:
cat /etc/security/tsd/ldap/tsd.dat | grep -p <your-own-cert-tag > /tmp/own_signed_stuff.dat
After this you can add this saved data to the local tsd.dat again with:
trustchk -R files -a -f /tmp/own_signed_stuff.dat
For the scripting people amongst us, a nice college of my made a sample script what you can reuse to make it work for your environment. It’s just mentioned as a example, please test it before you use it and modify It to your own needs. This script is rather large and therefore I did not paste this script in my blog. But if you send me a mail to my (TechExchange community mail) I will answer this mail and attach the script if liked.
This was the end of this TE blog series, hopefully it inspired you to use TE with is a great security feature of AIX.
I like have a special thank word to an IBM fellow who helped my out with several cases about this subject
Alexandre Blanke:
Thanks for all the support and help you give, clear explanations and solving our cases this is much appreciated!
I really appreciate any reaction and will respond to questions about this subject and other subjects.
I am preparing already my next subject for a blog, but any suggestions are welcome.
#IBMChampion
#ibmaix
