Pete Finnigan's Oracle Security Weblog

I saw a post by Tim Hall on his blog recently that referenced a new article he had written about the new fine grained network access controls added in 11g. As this is an area I have also looked at last year and also mentioned in a number of my presentations I was of course interested to have a look. I am never disapointed by any of Tim's papers which are always very well written and excellent.

This paper is particularly useful as the subject, if you think deeply about it quickly becomes complex. I noticed some issues with fine grained network access and also Tim has noticed some as well. The issues for me is that its controlled by ACL's through XML DB which is complex in its own right.

One of the key gotchas I noticed when testing this last year was that if you don't notice or understand that only one ACL can be assigned to a host or port range you can become unstuck. i.e. if you assign a new ACL to an existing specific host it deletes the last one silently. I mentioned this in my 11g security new features paper.

The other major gotcha that Tim didn't pick up on is the fact that the "fine grained control" is at the package group level, for the connect privilege this includes packages such as UTL_MAIL, UTL_HTTP, UTL_TCP...

Imagine the case where you want to grant access for connect on a specific host for a schema to access the UTL_MAIL package, fine and dandy but if you haven't been "specific" enough in defining the ACL (IP/ hostname AND port range) then you have also opened up access on the same host/port range to the other packages included in the FGNA controls. In this example the use of UTL_TCP is also available and that can be used to connect to any allowed port in the range and potentially then any protocol you can write in PL/SQL. In summary the protections are not fine grained enough on their own. You need to be specific with the ACL and if you want to allow access to MAIL, then allow access to only the ports 25(smtp) and 110(pop3) or one of them or different if they have moved or different protocols are used. Then revoke the access on all the packages affected by the connect privilege and allow grants back to the specific necessary schemas. Don't be lulled into a false sense of security if for instance the ACL is tied to the host and say just port 110, the UTL_TCP package if access is not revoked could be used to do more than the more limited set of actions the UTL_MAIL package offers.

Securing Oracle is always about depth, you need to ensure that no one can alter the ACL's, access the ACL's (dictionary views, package API's, raw XML), set up ACL's, revoke access to the functional packages..... there is more..... securing Oracle is always about depth. Whilst fine grained network access is a good move forward, you need to be careful that you don't think its a network security solution on its own!!