RE: Private Synonyms
- From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 21 Dec 2013 08:51:18 +0000
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
@jloracle
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] on behalf
of oracle@xxxxxxxxxxxxx [oracle@xxxxxxxxxxxxx]
Sent: 21 December 2013 02:01
To: jkstill@xxxxxxxxx; '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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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@xxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxx
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:
1) install the scott account, we'll need emp.
2) create another account, any name you like, I'll
use user1.
3) create a third account, I'll call it user2.
4) as scott grant select on emp to user1.
5) as scott grant select on emp to user2.
6) as user1 create a private synonym to scott.emp
7) 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
