Re: Trusted Hosts facility implementation frustration

Thanks Jonathan, this helps I fat-fingered the title here and actually knew it wasn't "trusted hosts" but my fingers weren't connected to my brain 7.31 on a Solaris machine, only using informix userid, no specific aao or dbsso I need to audit a particular column in a particular table and need to report what user accessed it. I also need to log key information for each row. Unfortunately, I DO need to audit row-level operations for my security people to be happy. I need to present them with an audit report that shows who accessed the specific row. I am hoping that when I present them with a ton of data, they will re-think their requirements. Jonathan Leffler wrote: > Doug McAllister@Fidelity Investments wrote: > > After attempting to read the Trusted Hosts manual and going in several > > loops with all of the circular references in the documentastion, I am > > ready to retire. > > Does anyone have any "readable" documentation with EXAMPLES on how to > > implement the Trusted Hosts Facility? Especially what the config files > > look like. > > 'Trusted Hosts' isn't recognizable - but I guess you are looking for > information about auditing and find the 'Trusted Facility' manual too > inscrutable? > > What are you seeking to audit? > > Do you need formal role separation - the DBSSO can't see what the AAO > can see and vice versa - or is group informix going to handle both roles? > > Which platform? Which version of IDS? It doesn't make a lot of > difference, but it is always a help to know. (For example, enabling > role separation on Windows is a re-install; it is not on Unix.) > > Potted guide - working mostly from memory, assuming no role separation: > > onaudit -l 7 -p /usr/informix/tmp -s 102400 -e 3 > onaudit -a -u _exclude -e +INRW,UPRW,DLRW,RDRW > onaudit -a -u _require -e +CRTB,DRTB,ACTB,STSN> > > The first command turns on auditing, placing the logs in > /usr/informix/tmp, setting the file size to 100KB, stopping the server > if there is an error, and auditing user informix as well as everyone else. > > The second ensures that the row-level operations are never audited. > > The third demands that create table, drop table, access table and start > session are audited for everyone. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

Doug McAllister@Fidelity Investments wrote: > Thanks Jonathan, this helps > I fat-fingered the title here and actually knew it wasn't "trusted > hosts" but my fingers weren't connected to my brain > > 7.31 on a Solaris machine, only using informix userid, no specific aao > or dbsso > > I need to audit a particular column in a particular table and need to > report what user accessed it. I also need to log key information for > each row. Unfortunately, I DO need to audit row-level operations for > my security people to be happy. I need to present them with an audit > report that shows who accessed the specific row. > I am hoping that when I present them with a ton of data, they will > re-think their requirements. > > Jonathan Leffler wrote: >> Doug McAllister@Fidelity Investments wrote: >>> After attempting to read the Trusted Hosts manual and going in several >>> loops with all of the circular references in the documentastion, I am >>> ready to retire. >>> Does anyone have any "readable" documentation with EXAMPLES on how to >>> implement the Trusted Hosts Facility? Especially what the config files >>> look like. >> 'Trusted Hosts' isn't recognizable - but I guess you are looking for >> information about auditing and find the 'Trusted Facility' manual too >> inscrutable? >> >> What are you seeking to audit? >> >> Do you need formal role separation - the DBSSO can't see what the AAO >> can see and vice versa - or is group informix going to handle both roles? >> >> Which platform? Which version of IDS? It doesn't make a lot of >> difference, but it is always a help to know. (For example, enabling >> role separation on Windows is a re-install; it is not on Unix.) >> >> Potted guide - working mostly from memory, assuming no role separation: >> >> onaudit -l 7 -p /usr/informix/tmp -s 102400 -e 3 >> onaudit -a -u _exclude -e +INRW,UPRW,DLRW,RDRW >> onaudit -a -u _require -e +CRTB,DRTB,ACTB,STSN>> >> >> The first command turns on auditing, placing the logs in >> /usr/informix/tmp, setting the file size to 100KB, stopping the server >> if there is an error, and auditing user informix as well as everyone else. >> >> The second ensures that the row-level operations are never audited. >> >> The third demands that create table, drop table, access table and start >> session are audited for everyone. As Mosser suggested, if you enable RDRW, you are going to get an audit record for every record read from every table in every database in the server instance. This is typically not a good idea - and you only get a ROWID to work with to track which data was actually read. Consequently, you are most likely to need to use some variant of triggers, as suggested by David. Look at the trigger introspection stuff that Jacques Roy documented out on DeveloperWorks. Be aware that standard SELECT triggers are very easy to evade - they are not good for auditing. The insert, delete and update triggers are reliable - select triggers are not. The big advantage of triggers will be that only the requisite table will be recorded - not every table. Yes, we are aware of these issues and are working towards improving this. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

Would Informix I-spy be of any use for this?

How can you evade standard select triggers?

On 5 Apr 2006 12:33:32 -0700, david@smooth1.co.uk <david@smooth1.co.uk> wrote: > How can you evade standard select triggers? SELECT * FROM TriggeredTable INTO TEMP Mine; SELECT * FROM Mine; That's just one easy way - there are many others. Do NOT use SELECT triggers for auditing! -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/