Re: Public execute on filetoclob and other fun....
A security audit flagged that PUBLIC can execute FILETOCLOB (and similar LOB functions) in sysmaster, and the poster asked whether revoking it there was safe. Responses noted sysmaster grants CONNECT/EXECUTE to PUBLIC by default, that "public" means authenticated users who still need OS file permissions, so the real security gain is limited; IBM support said the change can be made to silence the scanner. Risk to supportability was considered minimal. For the "routine ambiguous" error on revoke, the fix was to specify argument types (from sysprocedures.paramtypes), e.g. revoke execute on function lotofile(clob,lvarchar,char) from 'public'. The poster confirmed success.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Jesus Christ. Mac email mangles stuff nearly as badly as Notes! > On 5 Dec 2016, at 08:09, Spokey Wheeler <spokey.wheeler@gmail.com> wrote: > > If you regard FILETOCLOB as a UDR, then you can see the rules for UDR = > security here: = > http://www.ibm.com/support/knowledgecenter/SSGU8G_11.50.0/com.ibm.udr.doc/= > ids_udr_304.htm = > <http://www.ibm.com/support/knowledgecenter/SSGU8G_11.50.0/com.ibm.udr.doc= > /ids_udr_304.htm> > > I=E2=80=99m not sure why you=E2=80=99d make changes in sysmaster, you = > would just make the changes in your application=E2=80=99s database. You = > haven=E2=80=99t given everyone access to sysmaster, have you? :-) > > But if you have, I don=E2=80=99t see the problem. In other words, I = > agree with Squirrel. But I=E2=80=99m sure Art will be along shortly to = > prove me wrong! :-D > > Because if you don=E2=80=99t, you could=20 >> On 5 Dec 2016, at 07:55, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote: >> =20 >> Informix 11.7FC8=20 >> =20 >> Our auditors did an audit on our Informix databases using the SQuirrel = > tool.=20 >> Following is the finding and solution recommended by this tool.=20 >> =20 >> " database sysmaster=20 >> - Public can execute the filetoclob function. It is suggested that a = > role=20 >> called FileAccess be created and the execute permission for this = > routine be=20 >> assigned to this role. Users that, as a strict business requirement, = > need=20 >> access to this routine should be made members of this role. Once done, = > revoke=20 >> the execute permission from public. "=20 >> =20 >> I am not sure if we should make these changes in the Sysmaster = > database and if=20 >> creating a role in the sysmaster database is the best way to resolve = > this=20 >> finding.=20 >> Your views will be very much appreciated.=20 >> Thanks=20 >> =20 >> =20 >> = > **************************************************************************= > *****=20 >> Forum Note: Use "Reply" to post a response in the discussion forum.=20= > >> =20 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
I have not given anyone permissions to sysmaster database. My understanding according to the Squirrel report is that by default public has execute permission on this function and that the change is to be made in the Sysmaster database ?
Yes, sysmaster has CONNECT TO PUBLIC and most of it has SELECT / EXECUTE to PUBLIC. You asked about this recently, but I couldn't find any definitive answers. It may be better to open a PMR (hard question for tech support...) In the meanwhile, not that "public" means authenticated persons. And they will only get files on which they have OS access to. Even if you prevent the users from executing the functions they can load the files into tables with CLOB columns... My point is that although it would be easy to keep the tool happy, actually improving the security would be much harder.... Regards. On Mon, Dec 5, 2016 at 8:24 AM, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote: > I have not given anyone permissions to sysmaster database. My understanding > according to the Squirrel report is that by default public has execute > permission on this function and that the change is to be made in the > Sysmaster > database ? > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a114abc80714f9d0542e71114
I have logged a PMR with IBM and below is the reply I got. Consequently, it's possible make the change to avoid getting warnings from the security scanning tool. As alternative you can contact the security scanner vendor and ask them to change their built-in rules so the report is not made. There are more detailed information about license agreement you be able to get from IBM sales representative as IBM technical support do not cover license issues. Warm regards, Pavel Demidov
Well the question and part of the answer is missing.... I find it hard to see the relation with licensing... Regarding the security scanner tool... Hopefully it checks things like DB_LIBRARY_PATH and DBCREATE_PERMISSION? Regards. On Mon, Dec 5, 2016 at 11:38 AM, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote: > I have logged a PMR with IBM and below is the reply I got. > > Consequently, it's possible make the change to avoid getting warnings > from the security scanning tool. > As alternative you can contact the security scanner vendor and ask them > to change their built-in rules so the report is not made. > There are more detailed information about license agreement you be able > to get from IBM sales representative as IBM technical support do not > cover license issues. > > Warm regards, > Pavel Demidov > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --94eb2c0651e2b164860542e8478b
re license : If we make changes in sysmaster database what will the impact be on IBM support ?
This is by no means an official statement, but I believe it's common sense: When you open a PMR tech support doesn't know what "bad things" a customer may have done. It will proceed with the investigation. If customer did "something wrong" tech support will mention it and request that the customer fixes the situation to prove it solves the issue. If would help if you mention to tech support that you did some changes in sysmaster permissions (I've done it myself on customers, but in the opposite directions - provide more privileges on things that have been "closed"). So, I don't think anyone will ever tell you that no support will be provided because you changed things... Removing privileges on FILETO*OB doesn't sound like something that may have impact. But naturally if you note that something (remotely related) is not working you can grant the PUBLIC privilege again just to check. Most "critical" operations (if not all) like upgrades etc. will be run by Informix, so even if those functions were used, it shouldn't cause any issue. Regards. On Tue, Dec 6, 2016 at 8:37 AM, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote: > re license : If we make changes in sysmaster database what will the impact > be > on IBM support ? > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113fbb5a02d96a0542f99335
Thanks for your help it is very informative.
I am testing the "revoke execute on lotofile from 'public'" on a test server
but get the following message :
9700: Routine (lotofile) ambiguous - more than one routine resolves to given
signature.
wat would be the correct statement ?
revoke execute on function lotofile(blob,lvarchar,char) from 'public';
revoke execute on function lotofile(clob,lvarchar,char) from 'public';
For knowing what to use:
SELECT * FROM sysprocedures WHERE procname = 'your_function_here';
Regards.
On Tue, Dec 6, 2016 at 9:12 AM, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote:
> Thanks for your help it is very informative.
>
> I am testing the "revoke execute on lotofile from 'public'" on a test
> server
> but get the following message :
>
> 9700: Routine (lotofile) ambiguous - more than one routine resolves to> given
> signature.
>
> wat would be the correct statement ?
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--001a1147c69cb5f0bb0542fa04fd
When there are multiple routines with the same name overloaded you have to
specify the types of the arguments in the argument list in order to operate
on each specific procedure. You can get the argument list types from the
paramtypes column in sysprocedures:
select trim( procname ), paramtypes from sysprocedures where procname
matches 'fileto*';
Art
Art S. Kagel, President and Principal Consultant
ASK Database Management
www.askdbmgt.com
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.
On Tue, Dec 6, 2016 at 4:12 AM, FLIP VAN WYNGAARDT <flipv@raf.co.za> wrote:
> Thanks for your help it is very informative.
>
> I am testing the "revoke execute on lotofile from 'public'" on a test
> server
> but get the following message :
>
> 9700: Routine (lotofile) ambiguous - more than one routine resolves to> given
> signature.
>
> wat would be the correct statement ?
>
>
> ************************************************************
> *******************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a114b1106fdb5a30542fbc220
Thank you very much to every one. I manage to revoke public permissions on the lotofile and others.