RE: Privileges by session

From: <Joel.Patterson_at_crowley.com>
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-l
Received on Mon Jan 11 2010 - 06:53:46 CST

Original text of this message