The introduced behaviour enabled more user2/user1 interaction which increased the overall risk. User2 is more likely to trust SELECT'ing through user1's synonym than directly executing user1's stored proc.. ..But SELECT operations can be turned into code execution which makes SELECT'ing through another user's syns more insecure than folks initially give credit for. INHERIT privileges are a new way to reduce that risk. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jonathan Lewis Sent: 21 December 2013 08:51 To: oracle-l@xxxxxxxxxxxxx Subject: RE: Private Synonyms 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 -- //www.freelists.org/webpage/oracle-l