RE: Privileges by session
Date: Mon, 11 Jan 2010 07:53:46 -0500
Message-ID: <0684DA55864E404F8AD2E2EBDFD557DA03DD9919_at_JAXMSG01.crowley.com>
The site says this is unix based. Can you make a call to it from windows .net, java, visual basic, SQL*Server etc to get oracle passwords, (or any other passwords)?
I have a getpassword korn-shell script that could be used by unix programs, only thing left would be to encrypt decrypt my password file. I don't need it now, so no need to pursue it... and maybe opr.sourceforge.net could replace it... but we need to get to oracle from the desktops App servers.
Joel Patterson
Database Administrator
904 727-2546
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Pete Finnigan
Sent: Monday, January 11, 2010 3:22 AM
To: wblanchard_at_societyinsurance.com
Cc: oracle-l_at_freelists.org
Subject: Re: Privileges by session
Hi William,
There are lots of issues here. The first is that as jared points out you must fix the hard coded password problem.
There are plenty of solutions to this that might include:
1) have the password added by the SA's - not ideal as its still hard
coded
2) use Oracle wallets and mkstore to avoid the need to pass in the
password
3) use free software like opr.sourceforge.net to do similar
definetly do not share passwords for the application between dev and prod.
Use a firewall or valid node checking to ensure the app password is only used by the app. audit app use of system privileges and potentially connections from non-stanard IP's
The next issue is there is no such thing as a read-only user. Any user is in the public group and in 11gR1 this includes 27,000 otehr privileges some of which can be used to escalate your privileges. This means its not read-only.
Your ideas for restricting the read only accounts based on module/machine/IP etc are OK on a simple level. All these fields can easily be spoofed - search my blog for number of examples / links to papers on this.
Lock the developer account and only open it when its requested - i.e. priority one bug that requires live data to resolve.
Audit all system privileges on these read only accounts. Audit access to all objects in application schemas by these users.
Use valid node checking to limoit their access from one terminal each.
Use profiles to stop session duplication, careful use of resources etc.
Secure application roles are a good approach as well as a trigger (bear in mind what I said about spoofing)
cheers
Pete
Blanchard, William wrote:
> Greetings,
>
> I have convinced management to allow me to grant read-only access to
the
> developers. The problem is that they know the application passwords
and
> have been using those passwords to circumvent my controls. Is there a
> way via a trigger, role, etc to change individual sessions privileges
so
> they have read only (select) permissions? The easiest way would be to
> change the permissions on the applications but that's not an option.
>
> Thank you,
>
> WGB
>
>
> -
>
> This email and any information, files, or materials transmitted with
it
> are confidential and are solely for the use of the intended recipient.
> If you have received this email in error, please delete it and notify
> the sender.
>
>
>
-- Pete Finnigan Director PeteFinnigan.com Limited Specialists in database security. If you need help to audit or secure an Oracle database, please ask for details of our courses and consulting services Phone: +44 (0)1904 791188 Fax : +44 (0)1904 791188 Mob : +44 (0)7742 114223 email: pete_at_petefinnigan.com site : http://www.petefinnigan.com Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom Company No : 4664901 VAT No. : 940 6681 14 Please note that this email communication is intended only for the addressee and may contain confidential or privileged information. The contents of this email may be circulated internally within your organisation only and may not be communicated to third parties without the prior written permission of PeteFinnigan.com Limited. This email is not intended nor should it be taken to create any legal relations, contractual or otherwise. -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 11 2010 - 06:53:46 CST