RE: Private Synonyms
Date: Sat, 21 Dec 2013 08:51:18 +0000
Message-ID: <CE70217733273F49A8A162EE074F64D901DD2B09_at_exmbx05.thus.corp>
I may have missed something (pl/sql isn't my speciality), but this doesn't look like a NEW threat introduced by the synonym.
If you have privilege X that I want to use I create an invoker rights procedure and allow you to run it, telling you it's really useful You run it, and decide you really like using it - but it's running with (amongst other things) privilege X I then change the procedure to do something different (or extra, perhaps) that you can't see
No need for anything to do with any synonyms - I just have to ensure that you can't see the source of the procedure.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
_at_jloracle
From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] on behalf of oracle_at_ukcert.org.uk [oracle_at_ukcert.org.uk] Sent: 21 December 2013 02:01
To: jkstill_at_gmail.com; 'Niall Litchfield' Cc: 'Oracle-L Freelists'
Subject: RE: Private Synonyms
The post v8 behaviour enables user2 to select through user1's private syn,
but this can enable user2's privileges to transfer over to user1 through
INVOKER rights. user1 controls the private syn that user2 is selecting from
so can change that object to be a table with an index function, or whatever,
and whenever they like.
If user1 gains user2's privileges then it could access the additional data
that user2's invoking privileges allow. So there is a decrease in security
with the post v8 behaviour, but this is addressed with INHERIT privileges in
12c. INHERIT privileges adds a layer of permission requirement on top of
INVOKER rights to require the invoker to opt-in to allowing it's privileges
to be passed on in this way. HTH
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Jared Still
Sent: 20 December 2013 18:58
To: Niall Litchfield; Oracle-L Freelists
Subject: Re: Private Synonyms
What Niall said
On Dec 12, 2013 3:15 AM, "Niall Litchfield" <niall.litchfield_at_gmail.com> wrote:
There isn't a security breach in the sense that User 2 gets access to data that they didn't already have access to. It is however somewhat counter-intuitive that you can run
CREATE PRIVATE SYNONYM x for SCHEMA.OBJECT;
and that someone else can utilize your synonym without explicit grants. Doing so is somewhat daft of course..
On Thu, Dec 12, 2013 at 8:49 AM, D'Hooge Freek <Freek.DHooge_at_uptime.be> wrote:
Hi,
Why would that be fishy?
user2 has received access on the underlying object, to which
the private synonym points, directly from scott.
So, no security breach.
regards,
--
Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge_at_uptime.be
tel +32(03) 451 23 82 <tel:%2B32%2803%29%20451%2023%2082>
http://www.uptime.be
disclaimer: www.uptime.be/disclaimer.html
On wo, 2013-12-11 at 18:29 -0500, Dick Goulet wrote:
All,
Is there anyone other than myself that doesn't
think this is right. For those of you who have missed it, like I did, when
Oracle started evolving Fine Grained Access Controls (FGA) the role of
private synonyms changed. Try this for starters and I'll make it easy:
- install the scott account, we'll need emp.
- create another account, any name you like, I'll use user1.
- create a third account, I'll call it user2.
- as scott grant select on emp to user1.
- as scott grant select on emp to user2.
- as user1 create a private synonym to scott.emp
- as user2 "select * from user1.emp;"
If you go back to a V8 database step 7 above will
end in an ORA-00942. If your on V9 or higher, you get data.
Does this sound fishy??? I've opened an itar with
Oracle. They referenced note:174368.1 Policies on Synonyms. But this just
seems wrong to me. Any other opinion???
Dick Goulet
Senior Oracle DBA.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Sat Dec 21 2013 - 09:51:18 CET