This paper makes great reading. I will list and make some comments on the security related items as these are the most interesting for me.
ASM Command line tool : ASM is currently administered through SQL commands or OEM in 10g R1 where this new file system management feature was added. A new tool has been added in 10g Release 2, written in perl and called asmcmd. This tool allows a lot of things to be done to the datafiles stored in ASM diskgroups. This tool allows the DBA to give access to the sys admins who are not familiar with SQL and where the DBA does not want to give access to OEM for this purpose. This is a good security idea to limit access to specialised functionality so that an inexperienced person cannot do damage elsewhere. On the flip-side though a more accessible interface (for non Oracle specialists) does provide another avenue for those not familiar with SQL or OEM to mess with the datafiles. Quite clearly the access to these perl commands needs to also be guarded. Any shell scripts created to wrapper access to asmcmd should also be protected.
Direct SGA Access: This is a great (official) addition. It is well known that it is possible to query Oracle's share memory and consequently the X$ tables for a long time in home grown C programs. I have a few links to papers and code to do just this on my Undocumented Oracle page. Oracle Enterprise Manager Grid Control has had direct memory access methods added to it to allow it to automatically access memory on your behalf when the database is hung or too slow. You can also select this access mode in the user interface. I have not seen this myself but from Arup's description I would guess the scope is no where as near to what you can do yourself in C.
Online limit changes: Arup writes that it is now possible to change the values of parameters such as maxdatafiles without having to create a new control file in 10g R1. This means that RMAN will not lose stored information.
Manage multiple objects in OEM : You can now manage multiple objects without the need to create scripts with scripts from OEM Grid Control, this includes compiles, creating DDL and more. This could be a useful feature for effectively managing schemas and objects from a security point of view.
Audit trails in XML: This is a great new feature for 10g R2. Previoulsy if you chose to write audit to the OS for the additional security aspect of doing this (i.e. it is harder for a hacker to alter the audit trail if its on the OS than if it is in the database) then the files were written as verbose Oracle trace files. Now you can set the parameter audit_trail = xml and the parameter audit_file_dest to a suitable directory to get trace files written as standard XML with a .xml file extension. These files can then of course be easily parsed with an XML parser and as Arup points out could be loaded to the database as an XMLType. This would defeat the benefit of storing the audit trail on the OS of course, so whilst it can be useful for managing the audit data to place it into a database, the database used should be an independent one.
Event-base scheduling: The scheduler added in 10g R1 was a useful addition to the databases core functionality apart from early security issues. With 10g R2 it is now possible to trigger the scheduler based on events sent via the AQ mechanism. This could be useful in a security context for generating checks and reports based on actions performed in the database such as adding a user or changing a users privileges.
This is a good paper by Arup and summarises some great new features in 10g R2.