Rootkit Checker and Security Monitoring - Protecting Oracle Database 12c - page 189

being locked out. The point of the above is that root privilege cannot be controlled by EM. Root should be put under
break-glass and there should be a check before and after its use to verify integrity.
If an attacker does gain root access, then the only way to truly verify that the OS has not been backdoored is
to boot the disk to another OS, like a Linux live disk (e.g., Helix), and then use known-good checksums from that
live disk to compare to the potentially infected OS files on the target system. This is the realm of forensic operating
system response.
Note: I have covered forensic response in my previous book for Rampant Techpress. I have also placed a good
summary paper at the following URL: http://www.oracleforensics.com/wordpress/wp-content/uploads/2007/03/
OracleForensicsInANutshell.pdf .
Capabilities and Root
A capability is a single permission to carry out a task on a Unix file descriptor. The task can be read from memory or
a write to disk. The idea is to split root into its component capabilities and grant them individually to a user through
tokens, which can be removed but can't be forged.
An example of capability usage is to make a log file read-only by using chattr -V to make it immutable. The
following code does that:
chattr -V -i /u01/app/oracle/product/11.2.0/
dbhome_1/network/admin/listener.ora
Having made the file immutable, you can remove the capability to change the attribute from root, as follows:
lcap CAP_LINUX_IMMUTABLE
In my view, this approach is not recommended. My view is informed by the lcap man page (at http://linux.
die.net/man/8/lcap ), which states: “after you have adjusted your set of bound capabilities, you will need to remove
CAP_SYS_RAWIO and CAP_SYS_MODULE if you want to make sure that capabilities are not re-introduced.”
The problem with removing these capabilities is that doing so can result in an unstable system, as corroborated at
http://www.apress.com/9781590594445 (at the bottom of page 201).
A more realistic strategy for production systems should include monitoring as well as time limitations on
privileged sessions. More mature, and unfortunately costly, root controls include KEoN access routes, which give the
ability to run certain commands on certain hosts with root privileges (KEoN is now known as FoxT Server Control).
This is a reliable solution, but root can always find a way around, and just as the Oracle owner is secured by root, root
is secured by the physical layer in terms of network monitoring and physical data center access. Geographical access
to data centers is the bottom line. But what is new in the world of DB rootkits?
Self-replicating Rootkits
Fourth-generation database rootkits are self-replicating in that they piggy back the Oracle architecture to spread
malware. This has been seen already in the Windows world, where the enterprise-patching systems used to update
thousands of machines have been infected, thus replicating the malware automatically to many clients of that
enterprise-patching server.
.bsq Files
In an Oracle installation there are files used for the subsequent creation of new databases. These are called .bsq files.
A notable example of such a file is the following:
/home/oracle/app/oracle2/product/12.1.0/dbhome_2/rdbms/admin/dsec.bsq