AIX

 View Only

AIX and TE (Trusted Execution): an underestimated security feature? part1

By Christian Sonnemans posted Thu February 08, 2024 08:38 AM

  

What is TE (Trusted Execution)?

TE is one of the ways to protect AIX against intruders and hackers.

Last year I had some discussions with audit people that we should use a malware and intrusion detection system on our AIX Lpar’s. My answer to their arguments was, it’s already in place we use TE on AIX for this.

My goal for this blog series is to share knowledge about this very powerful easy to use feature.And in my humble opinion it should be used on every mission critical system with AIX, especially in a secure environment.

What are the arguments to use it and what are the benefits? 

Thats what I like to explain in this first part of this blog series.

Securing an operating system is getting more and more attention, and if I speak for myself it always got my special attention, working for a Dutch bank.

Well, speaking of benefits, TE fulfills perfectly the needs of a system administrator, see the list below:

When the right TE policies are enabled:

  • You can prove the integrity of the system.
  • Reliable proof that executables, libraries,  scripts  and files that belong to AIX are not tampered or modified and when they are tampered with they can no longer can be executed.    
  • Since AIX 7.2 TL 05 the same for AIX shared libraries, with lib.tsd.dat stored on LDAP.
  • Critical configuration files are locked and cannot be modified.
  • Add and sign your own executables and scripts to the database(s).
  • TE database for ALL the AIX commands are signed and approved by IBM, for every TL and SP.
  • TE-runtime is part of the AIX kernel and therefore abnormalities are immediately logged via syslog.
  •  Manual checks can be done via one single command, that can be used for auditing and prove the security state and sanity of the system and it identifies files that has changed.
  •  Even if configuration files are under control of automation tools, such as Ansible, TE locks all important configuration files, thus they cannot be modified without intervention of TE and/or RBAC commands.
  • For Ansible a default RBAC role can be put in place so that only Ansible is allowed to maintain config changes.
  • Increase the trust level of the system, when the right policies are enabled, a malicious user cannot harm the system, because files are locked (read-only).
  •  In the case that a script or executable or library is tampered with, execution is prohibited and the attempt to execute is logged *(runtime-TE).

And there are probably more arguments to give.

See also this link:

https://www.ibm.com/support/pages/node/6223934

A brief history:

TE was the successor or TCB (Trusted Computing Base) and was first introduced in AIX 6.1.

Even now in AIX 7.3 TCB is still available, but also IBM recommends to use TE instead of TCB.

TE is installed by default when on AIX 6.1 and higher and has much more flexibility than TCB and much better verification methods. See Note from IBM security_7.3:

TE is a more powerful and enhanced mechanism that overlaps some of the TCB functionality and provides advance security policies to better control the integrity of the system. While the Trusted Computing Base is still available, Trusted Execution introduces a new and more advanced concept of verifying and guarding the system integrity.

Basic knowledge:

How does it work and why it is fast and reliable?

TE in integrated into the AIX kernel and has it’s own database files: tsd.dat,  tepolicies.dat and libtsd.dat. Because it’s integrated into the kernel it’s fast.

Reliable, because every item that belongs to AIX  has an entry in the tsd / lib.tsd.dat is signed by IBM.

Database file by themselves are also locked (read only) if configured properly.

Those databases by default exist into the directory /etc/security/tsd and the last mentioned in /etc/security/tsd/lib.

The database files that are actually used are determined by the configuration file /etc/nscontrol.conf.

The last one is only important if you decide to store the database files on an secure Ldap sever (I will cover this setup in one of my next blogs).

So far this first blog about the AIX feature TE, my goal is to get your attention, and interest with this first part of the blog.

In the next blog I will explain more in depth the difference between passive and active mode and why they both are useful.

Furter I will explain the database files more in depth. And if this blog series is liked I can also share also how TE database files can be shared via Ldap server(s). And give some practical examples how to maintain TE after a SP or TL update.

10 comments
68 views

Permalink

Comments

Thu April 18, 2024 11:44 AM

I would like to check the signature using openssl, not trustchk.

I've been able to locate the certificate, and confirm the hash.

I tried converting the hex of the signature to binary and gave that to openssl without any luck.

Thu April 18, 2024 06:41 AM

Hello Russel,

I think you are searching for the following answers:

>> I've been digging into how the trusted execution database works, and where the values for each file comes from.

>> It's clear that the hash_value is a SHA256 of the file in question.

>> How can you verify the signature value against the certificate? I've found that the cert_tag >> is the certificate fingerprint of the certificate in /etc/security/certificates which I can view >> with openssl. What format is the signature?

See old (archived) Redbook sg24430 and also my blog part-2. But below part of this Redbook:

Ignore the bad example of telnet but it’s explains how it works:

4.2.2 Checking the signing authority

To answer the legitimate question “who has actually signed this binary?”, you

simply need to take a quick look at the TSD. First, you discover the certificate ID

the binary was signed with:

# trustchk -q /usr/sbin/telnetd|grep cert_tag

cert_tag = 00dcfcbcb7b0d911bd

Next, check if a file with that name exists in /etc/security/certificates and run this

command against that file:

# openssl x509 -inform DER -in 00dcfcbcb7b0d911bd -text -noout

The output might look similar to this:

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

dc:fc:bc:b7:b0:d9:11:bd

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, ST=TX, L=AU, O=IBM Corporation, OU=AIX,

CN=www.ibm.com

Validity

Not Before: Jan 25 06:33:57 2007 GMT

Not After : Jan 24 06:33:57 2010 GMT

Subject: C=US, ST=TX, L=AU, O=IBM Corporation, OU=AIX,

CN=www.ibm.com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (512 bit)

Modulus (512 bit):

00:ea:26:f5:08:c0:d4:14:29:91:31:ee:d7:6c:e5:

8c:71:a1:a8:d2:28:5d:ba:fd:f2:04:7d:b5:58:29:

c7:72:ea:64:0b:c6:7f:a8:f8:f0:75:c7:8f:1e:1a:

cc:f2:d1:fb:69:45:19:38:45:88:fc:38:5e:ea:3e:

d2:64:36:cb:63

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

F8:CE:2E:C3:D3:03:A3:B0:85:8D:1D:40:4B:82:A9:62:80:E9:01:35

X509v3 Authority Key Identifier:

keyid:F8:CE:2E:C3:D3:03:A3:B0:85:8D:1D:40:4B:82:A9:62:80:E9:01:35

DirName:/C=US/ST=TX/L=AU/O=IBM

Corporation/OU=AIX/CN=www.ibm.com

serial:DC:FC:BC:B7:B0:D9:11:BD

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: sha1WithRSAEncryption

79:c5:6c:dd:c5:8a:bb:1e:4d:71:1e:24:96:d2:96:a5:8a:86:

8a:ab:cd:7a:58:a2:2d:50:b2:8a:f1:c2:e9:81:81:9c:fe:c0:

90:5f:3d:57:fc:31:18:d4:11:6e:41:a9:b4:31:5f:35:06:ad:

92:07:ce:45:f0:31:7d:00:3c:7b

If you cannot find a matching file name, look at the default certificate called

/etc/security/certificates/certificate_540. The matching certificate has to be in

/etc/security/certificates, whatever its name might be. It is actually the

certificate’s ID that gets used by trustchk, but this ID does not necessarily have

to be the certificate’s file name as well. The TSD attribute cert_tag is in fact the

certificate’s serial number without colons and maybe some padding zeros at the

beginning. If no matching certificate is found at all on the system, integrity

checking will fail.

>> I did try converting the signature as a hexdump back to binary, and tried to validate the  >> signature with the certificate public key and an input file, but no luck.

See the above way how to check and verify.

>> Reading some of the documentation I see a reference to a "buildsecattr" tool. Where is that >> from?

Remember from my blogs the TDS is updated / composed during installing filesets, see the more in detail process below for the same (old) Redbook:

4.5.1 Adding BFF files to the TSD

When a fileset gets assembled into Backup File Format (BFF), the hash values

for the TSD get created using IBM keys and certificates.This is done with the

help of development tools like builtsecattr and instsecattr. Only the latter

one will be shipped with the AIX media. The instsecattr command is called by

installp and geninstall to add a trusted file’s stanza to the TSD in order to

guarantee the integrity of these files from IBM install media. If you do not use

BFF files, then trustchk will be used to add a trusted file’s stanza to the TSD.

In the Redbook there is a nice figure (4-2) that explains in a flow diagram how this works, but I cannot add pictures in a commend.

Please let me know if those were the answers your looking for?

Greetings Christian Sonnemans

Tue April 16, 2024 02:38 PM

I've been digging into how the trusted execution database works, and where the values for each file comes from.

It's clear that the hash_value is a SHA256 of the file in question.

How can you verify the signature value against the certificate? I've found that the cert_tag is the certificate fingerprint of the certificate in /etc/security/certificates which I can view with openssl. What format is the signature?

I did try converting the signature as a hexdump back to binary, and tried to validate the signature with the certificate public key and an input file, but no luck.

Reading some of the documentation I see a reference to a "buildsecattr" tool. Where is that from?

Fri March 29, 2024 03:03 PM

Hello Russel and other readers

Well I’ve got this question also from others and indeed it might be confusing.

But Trusted AIX and TE (Trusted execution) are two separate things!

See also link: https://www.ibm.com/docs/en/aix/7.2?topic=aix-introduction-trusted

What is removed in AIX 7.3 is Trusted AIX,  and NOT TE Trusted Execution.

Trusted AIX is installed form the start during installing AIX, it enables a labeling system, and store this labels in jfs2. It also installs several extra filesets, and created and activates Advanced RBAC and it’s default roles. Maybe this helps?

Fri March 29, 2024 08:51 AM

Perhaps you can help explain where TE is introduced, and what was removed in AIX 7.3 TL1. There are conflicting similarly named features.

https://www.ibm.com/docs/en/aix/7.3?topic=notes-aix-731-release

Security model updates in AIX 7.3.1

Starting with AIX 7.3, the following security models are not available. The following security options are removed from the Operating System Install menus and from the bosinst.data templates:
  • Trusted AIX
  • Trusted AIX LAS/EAL4+ Configuration Install
  • BAS and EAL4+ Configuration Install

Fri March 15, 2024 03:45 PM

Thank you for these TE contributions, Christian! I have circulated this information to some colleagues and added to the last White Paperr we had (from 61!!!) 

Wed February 14, 2024 08:43 AM

Christian, there are two things you've mentioned that I'd like to explore further with regard to TE. First, you mention storing the tsd.dat in LDAP. My familiarity with LDAP isn't deep. I know that we employ LDAP-based (I think) solutions for IAM across our enterprise, but AFAIK, this is limited to IAM (Identity and Access Management). Secondly, you mention having "several sets" for tsd.dat (and another for shared libraries?). I'd like to know more about how that is configured for AIX. This might permit us to "eat the elephant" one bite at a time, starting with the most vulnerable application environments within our enterprise.

Wed February 14, 2024 04:55 AM

Hello Macky Morgan

I like to respond to your concerns, and I do agree, a large environment with thousands of lpar’s it might a challenge to implement and maintain it on a right way, but using Ldap servers to store the database can help. Also, if you do not like the idea to locking files TE is still a good feature to check the sanity of the operating system, using TE in passive mode. (trustcheck -n ALL). I created a simple cronjob that does a checkup on daily basis and reports this, disadvantage here it’s of course reactive.

And yes, I am working for a Dutch bank and Dutch regulations enforce that we have an intrusion detection system, also on AIX. Maybe there is another intrusion detection system available for AIX? But my experience is quite good with TE, but on the other hand we do not have thousands of AIX servers running. Further I make and store several sets for the tsd.dat and store them on Ldap, for example for every level of AIX we store a different set on Ldap. Anyway, thanks for your comments, this helps to bring up the discussion this subject.  

Mon February 12, 2024 09:51 AM

I will be following with interest. The purpose and promise of TE is quite clear. The practicalities thereof, not so much. In an enterprise with thousands of AIX servers running different applications, it is my sense that TE would have to be tailored and tested (extensively!) individually to each server/application, and nobody has that kind of manpower on staff anymore. Moreover, it isn't just the UNIX Engineering staff who would need to understand the ins and outs of TE, the Build Teams, Patching Teams, Automation Teams, Recovery Teams, Production Support, etc, would also have to know TE intimately. Perhaps my biggest concern would be the vast number of INC tickets that would result from an attempt to "lock down" servers/applications with TE. I fear it would be a Whack-a-Mole of the highest order! But it you've got to lock down a machine, TE seems to provide the right tools to do so. But perhaps it should only be used on a carefully selected subset of the enterprise (say servers with Internet presence, PCI servers, etc.)? Change my mind.

Thu February 08, 2024 03:15 PM

Interesting indeed!