Role separation: DBSA, AAO, DBSSO command list?

Where to get complete/exact list of commands that randomUser and users that belong to AAO or DBSSO or DBSA can execute? I would like to find out what can users access and execute. So im looking for 4 lists: 1. List of commands/information that users of group AAO can execute/access? 2. List of commands/information that users of group DBSSO can execute/access? 3. List of commands/information that users of group DBSA can execute/access? 4. List of commands/information that users not in AAO or DBSSO or DBSA group can execute/access? So far OAT allow me to login as a randomUser that do not belong to ixaao,ixdbsso or informix group. As randomUser i was able to gain quite some info about my IDS, even php installation. Ofcourse i can simply delete randomUser to get rid of security threat, but this kind of access still apply to any other user that is needed. Im running IDS 12.10 with role separation enabled. current group settings for IDS: drwxrwxr-x. 2 informix ixaao 4096 Jun 11 07:46 aaodir drwxrwxr-x. 2 informix ixdbsso 4096 Jun 10 10:20 dbssodir drwxrwxr-x. 5 informix informix 4096 Jun 11 07:33 etc Any pointers to where i can find answers are welcome :)

Make sure that you do not have UNSECURE_ONSTAT set in the ONCONFIG file. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Jul 1, 2013 at 5:25 AM, MERIO MERTON <merton1234@outlook.com> wrote: > Where to get complete/exact list of commands that randomUser and users that > belong to AAO or DBSSO or DBSA can execute? > > I would like to find out what can users access and execute. So im looking > for > 4 lists: > > 1. List of commands/information that users of group AAO can execute/access? > 2. List of commands/information that users of group DBSSO can > execute/access? > 3. List of commands/information that users of group DBSA can > execute/access? > 4. List of commands/information that users not in AAO or DBSSO or DBSA > group > can execute/access? > > So far OAT allow me to login as a randomUser that do not belong to > ixaao,ixdbsso or informix group. As randomUser i was able to gain quite > some > info about my IDS, even php installation. > Ofcourse i can simply delete randomUser to get rid of security threat, but > this kind of access still apply to any other user that is needed. > > Im running IDS 12.10 with role separation enabled. > > current group settings for IDS: > drwxrwxr-x. 2 informix ixaao 4096 Jun 11 07:46 aaodir > drwxrwxr-x. 2 informix ixdbsso 4096 Jun 10 10:20 dbssodir > drwxrwxr-x. 5 informix informix 4096 Jun 11 07:33 etc > > Any pointers to where i can find answers are welcome :) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e013c6760d5422e04e0726ccf

Thanks for reply. The UNSECURE_ONSTAT option is at its default value which is 0 Disabled.

Hi Merio, My understanding of role separation is that it's entirely to do with auditing using 'onaudit', something that OAT doesn't support as far as I'm aware. So the audit analysis officer has access to the 'aaodir' to see the audit trail, the database security officer can set what is audited using 'onaudit' and DBAs just administer the system but not auditing and nor can they view the audit trail. See: http://pic.dhe.ibm.com/infocenter/idshelp/v117/index.jsp?topic=%2Fcom.ibm.sec.do c%2Fids_au_052.htm With regard to OAT, I suspect the problem you have is that ordinary users have a fair bit of access through the special "public" user. OAT can then use this to query system tables in the sysmaster database. So your problem is not with OAT as such. You can't run dbschema on the sysmaster database so you'll need to run something like this: > dbaccess sysmaster - Database selected. > select * from sysusers; username informix usertype D priority 9 password defrole username public usertype C priority 5 password defrole This shows that anyone can CONNECT by default. You can then see what access public has on tables with something like this: > select * from systabauth where grantee='public'; grantor informix grantee public tabid 1 tabauth s-------- grantor informix grantee public tabid 2 tabauth s-------- [snip] This is from a system with NODEFDAC set when it was built. I am not sure what the implications of removing these privileges are as I have never attempted to do so and I am not sure whether it's supported. I think you've asked an interesting question though and I would certainly be interested in whether a more locked-down configuration than the default is possible without causing application issues. A quick google revealed a previous IIUG discussion on this where it was suggested you could revoke the connect privilege from public on the sysmaster database. I think I would test this first unless anyone else can state it works. Ben.

Thanks for pointing out the public user privileges. Default IDS setup have a lot of public privileges set. That is why all users have a lot of access. Including aao,dbsso,dbsa users that i tested. Revoking public privileges and granting access to databases/tables on user by user basis is sure great for control. I revoke some public connect privileges on different databases/tables and so far OAT work as expected. On production server there sure will be no public privileges set or maybe some if really needed. Right now i focus on console/shell (direct access) and not so much OAT and privileges of accessing databases/tables. OAT gave me a quick info that i might be missing something regarding access to everything. That is why i start to explore in more detail what can users of certain group access. As of now i am still uncertain what exactly can member of each group execute/access from command line. In my case, AAO user will have access to shell and OAT. Shell to check audit log and OAT to check sql trail. Everyone like GUI so if there is a GUI for audit trail analysis that might be used in future. btw.....: audit log + sql trail != list of everything that happen on IDS maybe: audit log + sql trail + console log = list of everything that happen on IDS What is missing is another thing i need to find out. For instance: "onaudit -o" will not be in audit log. Using all masks listed in IBM Informix Security guide 12.10 except ALOC(page 12-2) which is not accepted by IDS. Maybe because it is developer edition. What i need is to be 100% sure what can each user do/see on IDS and log it ALL. Once i get all the facts i can set permissions and exclude non critical information from log.