• [Info-ingres] Protect Ingres procedure source

    From Paul White@21:1/5 to All on Sat May 1 17:52:24 2021
    This is a multi-part message in MIME format.
    Hi Ingres gurus.

    I would like to hide or encrypt the source code for a specific database procedure.
    I think it would involve disabling HELP PROCEDURE and restricting access
    to the iiprocedures system catalog.
    I would like to hide the rest of the schema as well.
    I think there is some capacity to block more system catalog tables as
    indicated by copydb behaviour (see below)

    I can restrict connection with a role and password, but once connected,
    there are several methods to extract schema and source from the database. Documentation on Encryption in the database indicates the feature is for
    data stored in user tables.

    example I have a row producing procedure:

    sql iidbdb
    * grant noselect_syscat on database testdb to pwhite\g\q

    sql testdb
    drop procedure if exists p_hidden
    \g

    create procedure p_hidden(v varchar(16))
    result row game(d ingresdate, msg varchar(50) not null with default)
    as
    declare
    d ingresdate;
    msg varchar(50);
    begin
    if  v = 'apple'  then
            msg = 'fruit'
    elseif  v = 'carrot'  then
            msg = 'vegetable'
    elseif  v = 'cow'  then
            msg = 'animal'
    elseif  v = 'truck'  then
            msg = 'mineral'
    else
            msg = 'dunno'
    endif;

    select :d = date('now');
    RETURN ROW(:d, :msg);
    end;
    \g

    grant execute on procedure p_hidden to public
    \g
    \q

    sql testdb -upwhite
    * select * from  p_hidden(v = 'apple'); \g

    +-------------------------+--------------------------------------------------+ |d                        |msg                                               |
    +-------------------------+--------------------------------------------------+ |01/05/21 16:37:15        |fruit                                             |
    +-------------------------+--------------------------------------------------+

    * select * from  p_hidden(v = 'carrot'); \g

    +-------------------------+--------------------------------------------------+ |d                        |msg                                               |
    +-------------------------+--------------------------------------------------+ |01/05/21 16:37:23        |vegetable                                         |
    +-------------------------+--------------------------------------------------+

    * help procedure p_hidden\g

    Procedure:            p_hidden
    Owner:                ingres
    Procedure Type:       native
    Object type:          user object
    Created:              01/05/21 16:37:08

    Procedure Definition:
    /*    1 */ create procedure  p_hidden(v varchar(16)) result row game(d ingresdate, msg varchar(50) not null with default) as declare d ingresdate;
    /*    2 */ msg varchar(50);
    /*    3 */ begin if v = 'apple' then msg = 'fruit' elseif v = 'carrot' then msg = 'vegetable' elseif v = 'cow' then msg = 'animal' elseif v = 'truck' then msg = 'mineral' else msg = 'dunno' endif;
    /*    4 */ select :d = date('now');
    /*    5 */ RETURN ROW(:d, :msg);
    /*    6 */ end

    Permissions on procedure p_hidden are:

    Permission 2:
    grant execute on procedure "ingres".p_hidden to public


    * select * from iiprocedures where procedure_name = 'p_hidden'\g |procedure_name|procedure_owner |create_date |proc_s|text_sequence |text_segment
    |p_hidden |ingres |2021_05_01 06:37:08 GMT |N | 1|create procedure p_hidden(v varchar(16)) result row game(d ingresdate, msg varchar(50) not null with default) as declare d ingresdat
    e; msg varchar(50); begin if v = 'apple' then msg = 'fruit' elseif v = 'carrot' then msg = 'vegetable' else|U |Y
    |p_hidden |ingres |2021_05_01 06:37:08 GMT |N | 2|if v = 'cow' then msg = 'animal' elseif v = 'truck' then msg = 'mineral' else msg = 'dunno' endif; select :d = date('now'); RETURN RO
    W(:d, :msg); end
    (2 rows)


    * select top 1 * from iirelation\g
    Executing . . .

    E_PS035A iirelation is a system catalog.
    You do not have appropriate privileges to directly query system catalogs
    (Sat May 1 17:07:35 2021)

    * select top 1 * from iitables\g
    |table_name |table_owner |create_date |alter_date |table_|table_|tab
    |ii_dbd_identifiers |$ingres |2019_07_01 01:23:04 GMT |2020_02_04 20:14:17 GMT |T |N |II1
    (1 row)


    Via Operating system user pwhite

    $ copydb testreet -with_proc
    INGRES COPYDB Copyright 2019 Actian Corporation
    Unload directory is '/home/pwhite'.
    Reload directory is '/home/pwhite'.
    E_PS035A iirelation is a system catalog.
        You do not have appropriate privileges to directly query system catalogs
        (Sat May  1 17:45:23 2021)

    There are 9 tables owned by user 'pwhite'.
    E_PS035A iiprocedure is a system catalog.
        You do not have appropriate privileges to directly query system catalogs
        (Sat May  1 17:45:23 2021)

    There are 0 procedures owned by user 'pwhite'.


    Paul


    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Hi Ingres gurus.</p>
    I would like to hide or encrypt the source code for a specific
    database procedure.<br>
    I think it would involve disabling HELP PROCEDURE and restricting
    access to the iiprocedures system catalog.<br>
    I would like to hide the rest of the schema as well. <br>
    I think there is some capacity to block more system catalog tables
    as indicated by copydb behaviour (see below)<br>
    <br>
    I can restrict connection with a role and password, but once
    connected, there are several methods to extract schema and source
    from the database.<br>
    Documentation on Encryption in the database indicates the feature is
    for data stored in user tables.<br>
    <br>
    <p>example I have a row producing procedure:</p>
    <pre>
    sql iidbdb
    * grant noselect_syscat on database testdb to pwhite\g\q

    sql testdb
    drop procedure if exists p_hidden
    \g

    create procedure p_hidden(v varchar(16))
    result row game(d ingresdate, msg varchar(50) not null with default)
    as
    declare
    d ingresdate;
    msg varchar(50);
    begin
    if  v = 'apple'  then
            msg = 'fruit'
    elseif  v = 'carrot'  then
            msg = 'vegetable'
    elseif  v = 'cow'  then
            msg = 'animal'
    elseif  v = 'truck'  then
            msg = 'mineral'
    else
            msg = 'dunno'
    endif;

    select :d = date('now');
    RETURN ROW(:d, :msg);
    end;
    \g

    grant execute on procedure p_hidden to public
    \g
    \q

    sql testdb -upwhite
    * select * from  p_hidden(v = 'apple'); \g

    +-------------------------+--------------------------------------------------+ |d                        |msg                                               |
    +-------------------------+--------------------------------------------------+ |01/05/21 16:37:15        |fruit                                             |
    +-------------------------+--------------------------------------------------+

    * select * from  p_hidden(v = 'carrot'); \g

    +-------------------------+--------------------------------------------------+ |d                        |msg                                               |
    +-------------------------+--------------------------------------------------+ |01/05/21 16:37:23        |vegetable                                         |
    +-------------------------+--------------------------------------------------+

    * help procedure p_hidden\g

    Procedure:            p_hidden
    Owner:                ingres
    Procedure Type:       native
    Object type:          user object
    Created:              01/05/21 16:37:08

    Procedure Definition:
    /*    1 */ create procedure  p_hidden(v varchar(16)) result row game(d ingresdate, msg varchar(50) not null with default) as declare d ingresdate;
    /*    2 */ msg varchar(50);
    /*    3 */ begin if v = 'apple' then msg = 'fruit' elseif v = 'carrot' then msg = 'vegetable' elseif v = 'cow' then msg = 'animal' elseif v = 'truck' then msg = 'mineral' else msg = 'dunno' endif;
    /*    4 */ select :d = date('now');
    /*    5 */ RETURN ROW(:d, :msg);
    /*    6 */ end

    Permissions on procedure p_hidden are:

    Permission 2:
    grant execute on procedure "ingres".p_hidden to public


    * select * from iiprocedures where procedure_name = 'p_hidden'\g |procedure_name|procedure_owner |create_date |proc_s|text_sequence |text_segment
    |p_hidden |ingres |2021_05_01 06:37:08 GMT |N | 1|create procedure p_hidden(v varchar(16)) result row game(d ingresdate, msg varchar(50) not null with default) as declare d ingresdat
    e; msg varchar(50); begin if v = 'apple' then msg = 'fruit' elseif v = 'carrot' then msg = 'vegetable' else|U |Y
    |p_hidden |ingres |2021_05_01 06:37:08 GMT |N | 2|if v = 'cow' then msg = 'animal' elseif v = 'truck' then msg = 'mineral' else msg = 'dunno' endif; select :d = date('now'); RETURN RO
    W(:d, :msg); end
    (2 rows)


    * select top 1 * from iirelation\g
    Executing . . .

    E_PS035A iirelation is a system catalog.
    You do not have appropriate privileges to directly query system catalogs
    (Sat May 1 17:07:35 2021)

    * select top 1 * from iitables\g
    |table_name |table_owner |create_date |alter_date |table_|table_|tab
    |ii_dbd_identifiers |$ingres |2019_07_01 01:23:04 GMT |2020_02_04 20:14:17 GMT |T |N |II1
    (1 row)

    </pre>
    <pre>

    Via Operating system user pwhite</pre>
    <pre>$ copydb testreet -with_proc
    INGRES COPYDB Copyright 2019 Actian Corporation
    Unload directory is '/home/pwhite'.
    Reload directory is '/home/pwhite'.
    E_PS035A iirelation is a system catalog.
        You do not have appropriate privileges to directly query system catalogs     (Sat May  1 17:45:23 2021)

    There are 9 tables owned by user 'pwhite'.
    E_PS035A iiprocedure is a system catalog.
        You do not have appropriate privileges to directly query system catalogs     (Sat May  1 17:45:23 2021)

    There are 0 procedures owned by user 'pwhite'.
    </pre>
    <p><br>
    </p>
    <p>Paul<br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roy Hann@21:1/5 to Paul White on Sat May 1 12:31:23 2021
    Paul White wrote:

    I would like to hide or encrypt the source code for a specific database procedure.

    To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it. Everything I thought of is easily subverted or breaks Ingres or (should) invalidate your support agreement.

    Roy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Karl Schendel@21:1/5 to All on Mon May 3 19:05:03 2021
    To: info-ingres@lists.planetingres.org

    I'm going to regret even suggesting this, but hey, whatever...

    If all the sessions that actually need to execute the DB procedures connect with some
    role identifier, I suspect you could manually revoke/drop the grant select to public on
    iiprocedure using a $ingres +U session, and manually grant select to the relevant role.
    This is off the top of my head and I don't know what other fallout it might cause.

    I think this might be the first time I've come across a valid use case for hiding
    DB procedure definitions, and it's worth some thought.

    Karl


    On May 3, 2021, at 6:56 PM, Paul White <paul.white@shift7solutions.com.au> wrote:

    Trying to create a view to hide the procedures...

    create view iiprocedures as select * from [$ingres].iiprocedures
    Executing . . .

    E_US13FC CREATE VIEW: Illegal tablename 'iiprocedures'. 'ii' is reserved for system catalogs.

    I have not found a way to hide proprietary / secret source code in stored procedures. I cannot hide the schema, tables, columns indices etc. As soon a user has a connection, for example ODBC, the database secrets can be mined. Here is my use case:

    OpenROAD, .Net and Web applications connect to a secure Ingres DB on Linux. Each User / Service has its own operating system account and password which allows validation. The DBusers are created without a password - but I am thinking of changing this.
    For Web and .Net apps, the connection DSN is encrypted in the config file. The service account has restricted access to specific user tables in database. The OpenROAD application uses a vnode with global connection definition. The first time a
    user runs the application, the local vnode definition is completed automatically using the client USERNAME. A unique password is generated to match the account in Linux. Crystal Reports use an ODBC connection which relies on a global fixed vnode and
    a fixed reporting user/password.



    I think, at this point, I have a number of options for protection:

    • Restrict connection to the Server O/S, firewall, client software controls.
    • Restrict Ingres services: iigcc, iigcd to specific ports
    • Restrict connection to the database with authentication / passwords at a number of levels: User, role, operating system, network (PAM), installation.
    • Once connected, restrict access to specific tables/columns using views, grants, procedures protected by user, role password, encryption and mask.
    • Restrict access to physical directories which store database files, checkpoints, journals. This is a default for Ingres installations.
    • Restrict user access to application or web portals eg Xenapp.
    • Use a report server to restrict access points from the reporting account.
    • Put sensitive / proprietary code into a library routine or call to an app server


    The gaps:

    A data mining tool can connect to ODBC and browse the database schema as report user. Even Excel can retrieve schema information

    The application role password is stored in OpenROAD. I think I can hide it in a compiled image and make it difficult (but not impossible) for a developer to debug.

    Service and reporting passwords are not secret. I can isolate DEV /QA / Production but it doesn't protect the schema.

    dbunload and copydb files are in plain text. Passwords are encrypted but not schema / procedural code.

    Web and .net config files have a DSN which I believe can be decrypted.


    On 1/05/2021 10:31 pm, Roy Hann wrote:

    Paul White wrote:


    I would like to hide or encrypt the source code for a specific database >>> procedure.

    To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it.
    Everything I thought of is easily subverted or breaks Ingres or (should)
    invalidate your support agreement.

    Roy
    _______________________________________________
    Info-ingres mailing list

    Info-ingres@lists.planetingres.org
    https://lists.planetingres.org/mailman/listinfo/info-ingres
    _______________________________________________
    Info-ingres mailing list
    Info-ingres@lists.planetingres.org https://lists.planetingres.org/mailman/listinfo/info-ingres

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul White@21:1/5 to Roy Hann on Tue May 4 08:56:02 2021
    This is a multi-part message in MIME format.
    Trying to create a view to hide the procedures...

    create view iiprocedures as select * from [$ingres].iiprocedures
    Executing . . .

    E_US13FC CREATE VIEW: Illegal tablename 'iiprocedures'. 'ii' is reserved for system catalogs.


    I have not found a way to hide proprietary / secret source code in
    stored procedures.  I cannot hide the schema, tables, columns indices
    etc. As soon a user has a connection, for example ODBC, the database
    secrets can be mined.  Here is my use case:

    OpenROAD, .Net and Web applications connect to a secure Ingres DB on
    Linux.  Each User / Service has its own operating system account and
    password which allows validation. The DBusers are created without a
    password - but I am thinking of changing this.    For Web and .Net apps,
    the connection DSN is encrypted in the config file.  The service account
    has restricted access to specific user tables in database.   The
    OpenROAD application uses a vnode with global connection definition. 
    The first time a user runs the application,  the local vnode definition
    is completed automatically using the client USERNAME.  A unique password
    is generated to match the account in Linux.   Crystal Reports use an
    ODBC connection which relies on a global fixed vnode and a fixed
    reporting user/password.


    I think, at this point, I have a number of options for protection:

    * Restrict connection to the Server O/S, firewall, client software
    controls.
    * Restrict Ingres services: iigcc, iigcd to specific ports
    * Restrict connection to the database with authentication / passwords
    at a number of levels: User, role, operating system, network (PAM),
    installation.
    * Once connected, restrict access to specific tables/columns using
    views, grants, procedures protected by user, role password,
    encryption and mask.
    * Restrict access to physical directories which store database files, 
    checkpoints, journals. This is a default for Ingres installations.
    * Restrict user access to application or web portals eg Xenapp.
    * Use a report server to restrict access points from the reporting
    account.
    * Put sensitive / proprietary code into a library routine or call to
    an app server


    The gaps:

    A data mining tool can connect to ODBC and browse the database schema as
    report user.  Even Excel can retrieve schema information

    The application role password is stored in OpenROAD.  I think I can hide
    it in a compiled image and make it difficult (but not impossible) for a developer to debug.

    Service and reporting passwords are not secret.  I can isolate DEV /QA / Production but it doesn't protect the schema.

    dbunload and copydb files are in plain text.  Passwords are encrypted
    but not schema / procedural code.

    Web and .net config files have a DSN which I believe can be decrypted.


    On 1/05/2021 10:31 pm, Roy Hann wrote:

    Paul White wrote:

    I would like to hide or encrypt the source code for a specific database
    procedure.
    To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it. Everything I thought of is easily subverted or breaks Ingres or (should) invalidate your support agreement.

    Roy
    _______________________________________________
    Info-ingres mailing list
    Info-ingres@lists.planetingres.org https://lists.planetingres.org/mailman/listinfo/info-ingres

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Trying to create a view to hide the procedures...<br>
    </p>
    <pre>create view iiprocedures as select * from [$ingres].iiprocedures Executing . . .</pre>
    <pre>E_US13FC CREATE VIEW: Illegal tablename 'iiprocedures'. 'ii' is reserved for system catalogs.</pre>
    <br>
    <p>I have not found a way to hide proprietary / secret source code
    in stored procedures.  I cannot hide the schema, tables, columns
    indices etc. As soon a user has a connection, for example ODBC,
    the database secrets can be mined.  Here is my use case:</p>
    <p>OpenROAD, .Net and Web applications connect to a secure Ingres DB
    on Linux.  Each User / Service has its own operating system
    account and password which allows validation. The DBusers are
    created without a password - but I am thinking of changing this.
       For Web and .Net apps, the connection DSN is encrypted in the
    config file.  The service account has restricted access to
    specific user tables in database.   The OpenROAD application uses
    a vnode with global connection definition.  The first time a user
    runs the application,  the local vnode definition is completed
    automatically using the client USERNAME.  A unique password is
    generated to match the account in Linux.   Crystal Reports use an
    ODBC connection which relies on a global fixed vnode and a fixed
    reporting user/password.</p>
    <p><br>
    </p>
    <p>I think, at this point, I have a number of options for
    protection:</p>
    <ul>
    <li>Restrict connection to the Server O/S, firewall, client
    software controls.</li>
    <li>Restrict Ingres services: iigcc, iigcd to specific ports<br>
    </li>
    <li>Restrict connection to the database with authentication /
    passwords at a number of levels: User, role, operating system,
    network (PAM), installation.<br>
    </li>
    <li>Once connected, restrict access to specific tables/columns
    using views, grants, procedures protected by user, role
    password, encryption and mask.</li>
    <li>Restrict access to physical directories which store database
    files,  checkpoints, journals. This is a default for Ingres
    installations.</li>
    <li>Restrict user access to application or web portals eg Xenapp.</li>
    <li>Use a report server to restrict access points from the
    reporting account.</li>
    <li>Put sensitive / proprietary code into a library routine or
    call to an app server<br>
    </li>
    </ul>
    <p><br>
    </p>
    <p>The gaps:</p>
    <p>A data mining tool can connect to ODBC and browse the database
    schema as report user.  Even Excel can retrieve schema information</p>
    <p>The application role password is stored in OpenROAD.  I think I
    can hide it in a compiled image and make it difficult (but not
    impossible) for a developer to debug.<br>
    </p>
    <p>Service and reporting passwords are not secret.  I can isolate
    DEV /QA / Production but it doesn't protect the schema.</p>
    <p>dbunload and copydb files are in plain text.  Passwords are
    encrypted but not schema / procedural code.</p>
    <p>Web and .net config files have a DSN which I believe can be
    decrypted. <br>
    </p>
    <br>
    <p>On 1/05/2021 10:31 pm, Roy Hann wrote:<br>
    </p>
    <blockquote type="cite" cite="mid:s6jhmq$v10$1@gioia.aioe.org">
    <pre class="moz-quote-pre" wrap="">Paul White wrote:

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">I would like to hide or encrypt the source code for a specific database
    procedure.
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">
    To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it. Everything I thought of is easily subverted or breaks Ingres or (should) invalidate your support agreement.

    Roy
    _______________________________________________
    Info-ingres mailing list
    <a class="moz-txt-link-abbreviated" href="mailto:Info-ingres@lists.planetingres.org">Info-ingres@lists.planetingres.org</a>
    <a class="moz-txt-link-freetext" href="https://lists.planetingres.org/mailman/listinfo/info-ingres">https://lists.planetingres.org/mailman/listinfo/info-ingres</a>
    </pre>
    </blockquote>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul White@21:1/5 to Karl Schendel on Tue May 4 12:01:19 2021
    To: info-ingres@lists.planetingres.org

    This is a multi-part message in MIME format.
    It was worth a try

    sql xpw +U -u'$ingres' -s
    set autocommit on;
    revoke all on iiprocedure from public restrict;
    E_US138E Table is in use. End other transactions using the table and try again.


    On 4/05/2021 9:05 am, Karl Schendel wrote:
    I'm going to regret even suggesting this, but hey, whatever...

    If all the sessions that actually need to execute the DB procedures connect with some
    role identifier, I suspect you could manually revoke/drop the grant select to public on
    iiprocedure using a $ingres +U session, and manually grant select to the relevant role.
    This is off the top of my head and I don't know what other fallout it might cause.

    I think this might be the first time I've come across a valid use case for hiding
    DB procedure definitions, and it's worth some thought.

    Karl


    On May 3, 2021, at 6:56 PM, Paul White <paul.white@shift7solutions.com.au> wrote:

    Trying to create a view to hide the procedures...

    create view iiprocedures as select * from [$ingres].iiprocedures
    Executing . . .

    E_US13FC CREATE VIEW: Illegal tablename 'iiprocedures'. 'ii' is reserved for system catalogs.

    I have not found a way to hide proprietary / secret source code in stored procedures. I cannot hide the schema, tables, columns indices etc. As soon a user has a connection, for example ODBC, the database secrets can be mined. Here is my use case:

    OpenROAD, .Net and Web applications connect to a secure Ingres DB on Linux. Each User / Service has its own operating system account and password which allows validation. The DBusers are created without a password - but I am thinking of changing this.
    For Web and .Net apps, the connection DSN is encrypted in the config file. The service account has restricted access to specific user tables in database. The OpenROAD application uses a vnode with global connection definition. The first time a
    user runs the application, the local vnode definition is completed automatically using the client USERNAME. A unique password is generated to match the account in Linux. Crystal Reports use an ODBC connection which relies on a global fixed vnode and
    a fixed reporting user/password.



    I think, at this point, I have a number of options for protection:

    • Restrict connection to the Server O/S, firewall, client software controls.
    • Restrict Ingres services: iigcc, iigcd to specific ports
    • Restrict connection to the database with authentication / passwords at a number of levels: User, role, operating system, network (PAM), installation.
    • Once connected, restrict access to specific tables/columns using views, grants, procedures protected by user, role password, encryption and mask.
    • Restrict access to physical directories which store database files, checkpoints, journals. This is a default for Ingres installations.
    • Restrict user access to application or web portals eg Xenapp.
    • Use a report server to restrict access points from the reporting account.
    • Put sensitive / proprietary code into a library routine or call to an app server


    The gaps:

    A data mining tool can connect to ODBC and browse the database schema as report user. Even Excel can retrieve schema information

    The application role password is stored in OpenROAD. I think I can hide it in a compiled image and make it difficult (but not impossible) for a developer to debug.

    Service and reporting passwords are not secret. I can isolate DEV /QA / Production but it doesn't protect the schema.

    dbunload and copydb files are in plain text. Passwords are encrypted but not schema / procedural code.

    Web and .net config files have a DSN which I believe can be decrypted.


    On 1/05/2021 10:31 pm, Roy Hann wrote:

    Paul White wrote:


    I would like to hide or encrypt the source code for a specific database >>>> procedure.

    To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it.
    Everything I thought of is easily subverted or breaks Ingres or (should) >>> invalidate your support agreement.

    Roy
    _______________________________________________
    Info-ingres mailing list

    Info-ingres@lists.planetingres.org
    https://lists.planetingres.org/mailman/listinfo/info-ingres
    _______________________________________________
    Info-ingres mailing list
    Info-ingres@lists.planetingres.org
    https://lists.planetingres.org/mailman/listinfo/info-ingres
    _______________________________________________
    Info-ingres mailing list
    Info-ingres@lists.planetingres.org https://lists.planetingres.org/mailman/listinfo/info-ingres

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <pre>It was worth a try

    </pre>
    <pre>sql xpw +U -u'$ingres' -s
    set autocommit on;
    revoke all on iiprocedure from public restrict;
    E_US138E Table is in use. End other transactions using the table and try again.</pre>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/05/2021 9:05 am, Karl Schendel
    wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:30433FEB-E59D-4179-B4FA-FC759E8D33FA@kbcomputer.com">
    <pre class="moz-quote-pre" wrap="">I'm going to regret even suggesting this, but hey, whatever...

    If all the sessions that actually need to execute the DB procedures connect with some
    role identifier, I suspect you could manually revoke/drop the grant select to public on
    iiprocedure using a $ingres +U session, and manually grant select to the relevant role.
    This is off the top of my head and I don't know what other fallout it might cause.

    I think this might be the first time I've come across a valid use case for hiding
    DB procedure definitions, and it's worth some thought.

    Karl


    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">On May 3, 2021, at 6:56 PM, Paul White <a class="moz-txt-link-rfc2396E" href="mailto:paul.white@shift7solutions.com.au">&lt;paul.white@shift7solutions.com.au&gt;</a> wrote:

    Trying to create a view to hide the procedures...

    create view iiprocedures as select * from [$ingres].iiprocedures
    Executing . . .

    E_US13FC CREATE VIEW: Illegal tablename 'iiprocedures'. 'ii' is reserved for system catalogs.

    I have not found a way to hide proprietary / secret source code in stored procedures. I cannot hide the schema, tables, columns indices etc. As soon a user has a connection, for example ODBC, the database secrets can be mined. Here is my use case:

    OpenROAD, .Net and Web applications connect to a secure Ingres DB on Linux. Each User / Service has its own operating system account and password which allows validation. The DBusers are created without a password - but I am thinking of changing this.
    For Web and .Net apps, the connection DSN is encrypted in the config file. The service account has restricted access to specific user tables in database. The OpenROAD application uses a vnode with global connection definition. The first time a user
    runs the application, the local vnode definition is completed automatically using the client USERNAME. A unique password is generated to match the account in Linux. Crystal Reports use an ODBC connection which relies on a global fixed vnode and a
    fixed reporting user/password.



    I think, at this point, I have a number of options for protection:

    • Restrict connection to the Server O/S, firewall, client software controls.
    • Restrict Ingres services: iigcc, iigcd to specific ports
    • Restrict connection to the database with authentication / passwords at a number of levels: User, role, operating system, network (PAM), installation.
    • Once connected, restrict access to specific tables/columns using views, grants, procedures protected by user, role password, encryption and mask.
    • Restrict access to physical directories which store database files, checkpoints, journals. This is a default for Ingres installations.
    • Restrict user access to application or web portals eg Xenapp.
    • Use a report server to restrict access points from the reporting account.
    • Put sensitive / proprietary code into a library routine or call to an app server


    The gaps:

    A data mining tool can connect to ODBC and browse the database schema as report user. Even Excel can retrieve schema information

    The application role password is stored in OpenROAD. I think I can hide it in a compiled image and make it difficult (but not impossible) for a developer to debug.

    Service and reporting passwords are not secret. I can isolate DEV /QA / Production but it doesn't protect the schema.

    dbunload and copydb files are in plain text. Passwords are encrypted but not schema / procedural code.

    Web and .net config files have a DSN which I believe can be decrypted.


    On 1/05/2021 10:31 pm, Roy Hann wrote:

    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">Paul White wrote:


    </pre>
    <blockquote type="cite">
    <pre class="moz-quote-pre" wrap="">I would like to hide or encrypt the source code for a specific database
    procedure.

    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">To stop myself fussing with this loose tooth I am going to
    publicly declare defeat so I can move on. I don't see a way to do it. Everything I thought of is easily subverted or breaks Ingres or (should) invalidate your support agreement.

    Roy
    _______________________________________________
    Info-ingres mailing list

    <a class="moz-txt-link-abbreviated" href="mailto:Info-ingres@lists.planetingres.org">Info-ingres@lists.planetingres.org</a>
    <a class="moz-txt-link-freetext" href="https://lists.planetingres.org/mailman/listinfo/info-ingres">https://lists.planetingres.org/mailman/listinfo/info-ingres</a>
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">_______________________________________________
    Info-ingres mailing list
    <a class="moz-txt-link-abbreviated" href="mailto:Info-ingres@lists.planetingres.org">Info-ingres@lists.planetingres.org</a>
    <a class="moz-txt-link-freetext" href="https://lists.planetingres.org/mailman/listinfo/info-ingres">https://lists.planetingres.org/mailman/listinfo/info-ingres</a>
    </pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap=""> _______________________________________________
    Info-ingres mailing list
    <a class="moz-txt-link-abbreviated" href="mailto:Info-ingres@lists.planetingres.org">Info-ingres@lists.planetingres.org</a>
    <a class="moz-txt-link-freetext" href="https://lists.planetingres.org/mailman/listinfo/info-ingres">https://lists.planetingres.org/mailman/listinfo/info-ingres</a>
    </pre>
    </blockquote>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Bowes@21:1/5 to Karl Schendel on Tue May 4 09:23:55 2021
    To: paul.white@shift7solutions.com.au (paul.white@shift7solutions.com.au)
    To: info-ingres@lists.planetingres.org (info-ingres@lists.planetingres.org)

    SGkgQWxsLA0KDQpPdXQgb2YgY3VyaW9zaXR5Li4uDQoNCkkgc2VlIGluIDExLjIgdGhhdCB3ZSB3 aWxsIGJlIGFibGUgdG8gY3JlYXRlIGZ1bmN0aW9uLCBmdXJ0aGVyIHRoYXQgd2UgY2FuIHNwZWNp ZnkgdGhlIGxhbmd1YWdlIGFzIFNRTC4NCg0KV2lsbCB0aGVyZSBiZSBhIGhlbHAgZnVuY3Rpb24g Y29tbWFuZCBhcyBwZXIgaGVscCBwcm9jZWR1cmU/IElmIG5vdCB0aGVuIHRoZSBhbnN3ZXIgdG8g UGF1bCdzIHByb2JsZW0gbWF5IGJlIHRvIHVwZ3JhZGUgdG8gMTEuMiAod2hlbiByZWxlYXNlZCkg YW5kIHJlcGxhY2UgdGhlIHByb2NlZHVyZSB3aXRoIGEgZnVuY3Rpb24uDQoNCk1hcnR5DQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLYXJsIFNjaGVuZGVsIDxzY2hlbmRlbEBr YmNvbXB1dGVyLmNvbT4gDQpTZW50OiAwNCBNYXkgMjAyMSAwMDowNQ0KVG86IHBhdWwud2hpdGVA c2hpZnQ3c29sdXRpb25zLmNvbS5hdTsgaW5mby1pbmdyZXNAbGlzdHMucGxhbmV0aW5ncmVzLm9y Zw0KU3ViamVjdDogUmU6IFtJbmZvLWluZ3Jlc10gUHJvdGVjdCBJbmdyZXMgcHJvY2VkdXJlIHNv dXJjZQ0KDQpJJ20gZ29pbmcgdG8gcmVncmV0IGV2ZW4gc3VnZ2VzdGluZyB0aGlzLCBidXQgaGV5 LCB3aGF0ZXZlci4uLg0KDQpJZiBhbGwgdGhlIHNlc3Npb25zIHRoYXQgYWN0dWFsbHkgbmVlZCB0 byBleGVjdXRlIHRoZSBEQiBwcm9jZWR1cmVzIGNvbm5lY3Qgd2l0aCBzb21lIHJvbGUgaWRlbnRp ZmllciwgSSBzdXNwZWN0IHlvdSBjb3VsZCBtYW51YWxseSByZXZva2UvZHJvcCB0aGUgZ3JhbnQg c2VsZWN0IHRvIHB1YmxpYyBvbiBpaXByb2NlZHVyZSB1c2luZyBhICRpbmdyZXMgK1Ugc2Vzc2lv biwgYW5kIG1hbnVhbGx5IGdyYW50IHNlbGVjdCB0byB0aGUgcmVsZXZhbnQgcm9sZS4NClRoaXMg aXMgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCBhbmQgSSBkb24ndCBrbm93IHdoYXQgb3RoZXIgZmFs bG91dCBpdCBtaWdodCBjYXVzZS4NCg0KSSB0aGluayB0aGlzIG1pZ2h0IGJlIHRoZSBmaXJzdCB0 aW1lIEkndmUgY29tZSBhY3Jvc3MgYSB2YWxpZCB1c2UgY2FzZSBmb3IgaGlkaW5nIERCIHByb2Nl ZHVyZSBkZWZpbml0aW9ucywgYW5kIGl0J3Mgd29ydGggc29tZSB0aG91Z2h0Lg0KDQpLYXJsDQoN Cg0KPiBPbiBNYXkgMywgMjAyMSwgYXQgNjo1NiBQTSwgUGF1bCBXaGl0ZSA8cGF1bC53aGl0ZUBz aGlmdDdzb2x1dGlvbnMuY29tLmF1PiB3cm90ZToNCj4gDQo+IFRyeWluZyB0byBjcmVhdGUgYSB2 aWV3IHRvIGhpZGUgdGhlIHByb2NlZHVyZXMuLi4NCj4gDQo+IGNyZWF0ZSB2aWV3IGlpcHJvY2Vk dXJlcyBhcyBzZWxlY3QgKiBmcm9tIFskaW5ncmVzXS5paXByb2NlZHVyZXMgDQo+IEV4ZWN1dGlu ZyAuIC4gLg0KPiANCj4gRV9VUzEzRkMgQ1JFQVRFIFZJRVc6IElsbGVnYWwgdGFibGVuYW1lICdp aXByb2NlZHVyZXMnLiAnaWknIGlzIHJlc2VydmVkIGZvciBzeXN0ZW0gY2F0YWxvZ3MuDQo+IA0K PiBJIGhhdmUgbm90IGZvdW5kIGEgd2F5IHRvIGhpZGUgcHJvcHJpZXRhcnkgLyBzZWNyZXQgc291 cmNlIGNvZGUgaW4gc3RvcmVkIHByb2NlZHVyZXMuICBJIGNhbm5vdCBoaWRlIHRoZSBzY2hlbWEs IHRhYmxlcywgY29sdW1ucyBpbmRpY2VzIGV0Yy4gQXMgc29vbiBhIHVzZXIgaGFzIGEgY29ubmVj dGlvbiwgZm9yIGV4YW1wbGUgT0RCQywgdGhlIGRhdGFiYXNlIHNlY3JldHMgY2FuIGJlIG1pbmVk LiAgSGVyZSBpcyBteSB1c2UgY2FzZToNCj4gDQo+IE9wZW5ST0FELCAuTmV0IGFuZCBXZWIgYXBw bGljYXRpb25zIGNvbm5lY3QgdG8gYSBzZWN1cmUgSW5ncmVzIERCIG9uIExpbnV4LiAgRWFjaCBV c2VyIC8gU2VydmljZSBoYXMgaXRzIG93biBvcGVyYXRpbmcgc3lzdGVtIGFjY291bnQgYW5kIHBh c3N3b3JkIHdoaWNoIGFsbG93cyB2YWxpZGF0aW9uLiBUaGUgREJ1c2VycyBhcmUgY3JlYXRlZCB3 aXRob3V0IGEgcGFzc3dvcmQgLSBidXQgSSBhbSB0aGlua2luZyBvZiBjaGFuZ2luZyB0aGlzLiAg ICBGb3IgV2ViIGFuZCAuTmV0IGFwcHMsIHRoZSBjb25uZWN0aW9uIERTTiBpcyBlbmNyeXB0ZWQg aW4gdGhlIGNvbmZpZyBmaWxlLiAgVGhlIHNlcnZpY2UgYWNjb3VudCBoYXMgcmVzdHJpY3RlZCBh Y2Nlc3MgdG8gc3BlY2lmaWMgdXNlciB0YWJsZXMgaW4gZGF0YWJhc2UuICAgVGhlIE9wZW5ST0FE IGFwcGxpY2F0aW9uIHVzZXMgYSB2bm9kZSB3aXRoIGdsb2JhbCBjb25uZWN0aW9uIGRlZmluaXRp b24uICBUaGUgZmlyc3QgdGltZSBhIHVzZXIgcnVucyB0aGUgYXBwbGljYXRpb24sICB0aGUgbG9j YWwgdm5vZGUgZGVmaW5pdGlvbiBpcyBjb21wbGV0ZWQgYXV0b21hdGljYWxseSB1c2luZyB0aGUg Y2xpZW50IFVTRVJOQU1FLiAgQSB1bmlxdWUgcGFzc3dvcmQgaXMgZ2VuZXJhdGVkIHRvIG1hdGNo IHRoZSBhY2NvdW50IGluIExpbnV4LiAgIENyeXN0YWwgUmVwb3J0cyB1c2UgYW4gT0RCQyBjb25u ZWN0aW9uIHdoaWNoIHJlbGllcyBvbiBhIGdsb2JhbCBmaXhlZCB2bm9kZSBhbmQgYSBmaXhlZCBy ZXBvcnRpbmcgdXNlci9wYXNzd29yZC4NCj4gDQo+IA0KPiANCj4gSSB0aGluaywgYXQgdGhpcyBw b2ludCwgSSBoYXZlIGEgbnVtYmVyIG9mIG9wdGlvbnMgZm9yIHByb3RlY3Rpb246DQo+IA0KPiAJ 4oCiIFJlc3RyaWN0IGNvbm5lY3Rpb24gdG8gdGhlIFNlcnZlciBPL1MsIGZpcmV3YWxsLCBjbGll bnQgc29mdHdhcmUgY29udHJvbHMuDQo+IAnigKIgUmVzdHJpY3QgSW5ncmVzIHNlcnZpY2VzOiBp aWdjYywgaWlnY2QgdG8gc3BlY2lmaWMgcG9ydHMNCj4gCeKAoiBSZXN0cmljdCBjb25uZWN0aW9u IHRvIHRoZSBkYXRhYmFzZSB3aXRoIGF1dGhlbnRpY2F0aW9uIC8gcGFzc3dvcmRzIGF0IGEgbnVt YmVyIG9mIGxldmVsczogVXNlciwgcm9sZSwgb3BlcmF0aW5nIHN5c3RlbSwgbmV0d29yayAoUEFN KSwgaW5zdGFsbGF0aW9uLg0KPiAJ4oCiIE9uY2UgY29ubmVjdGVkLCByZXN0cmljdCBhY2Nlc3Mg dG8gc3BlY2lmaWMgdGFibGVzL2NvbHVtbnMgdXNpbmcgdmlld3MsIGdyYW50cywgcHJvY2VkdXJl cyBwcm90ZWN0ZWQgYnkgdXNlciwgcm9sZSBwYXNzd29yZCwgZW5jcnlwdGlvbiBhbmQgbWFzay4N Cj4gCeKAoiBSZXN0cmljdCBhY2Nlc3MgdG8gcGh5c2ljYWwgZGlyZWN0b3JpZXMgd2hpY2ggc3Rv cmUgZGF0YWJhc2UgZmlsZXMsICBjaGVja3BvaW50cywgam91cm5hbHMuIFRoaXMgaXMgYSBkZWZh dWx0IGZvciBJbmdyZXMgaW5zdGFsbGF0aW9ucy4NCj4gCeKAoiBSZXN0cmljdCB1c2VyIGFjY2Vz cyB0byBhcHBsaWNhdGlvbiBvciB3ZWIgcG9ydGFscyBlZyBYZW5hcHAuDQo+IAnigKIgVXNlIGEg cmVwb3J0IHNlcnZlciB0byByZXN0cmljdCBhY2Nlc3MgcG9pbnRzIGZyb20gdGhlIHJlcG9ydGlu ZyBhY2NvdW50Lg0KPiAJ4oCiIFB1dCBzZW5zaXRpdmUgLyBwcm9wcmlldGFyeSBjb2RlIGludG8g YSBsaWJyYXJ5IHJvdXRpbmUgb3IgY2FsbCB0byANCj4gYW4gYXBwIHNlcnZlcg0KPiANCj4gDQo+ IFRoZSBnYXBzOg0KPiANCj4gQSBkYXRhIG1pbmluZyB0b29sIGNhbiBjb25uZWN0IHRvIE9EQkMg YW5kIGJyb3dzZSB0aGUgZGF0YWJhc2Ugc2NoZW1hIA0KPiBhcyByZXBvcnQgdXNlci4gIEV2ZW4g RXhjZWwgY2FuIHJldHJpZXZlIHNjaGVtYSBpbmZvcm1hdGlvbg0KPiANCj4gVGhlIGFwcGxpY2F0 aW9uIHJvbGUgcGFzc3dvcmQgaXMgc3RvcmVkIGluIE9wZW5ST0FELiAgSSB0aGluayBJIGNhbiBo aWRlIGl0IGluIGEgY29tcGlsZWQgaW1hZ2UgYW5kIG1ha2UgaXQgZGlmZmljdWx0IChidXQgbm90 IGltcG9zc2libGUpIGZvciBhIGRldmVsb3BlciB0byBkZWJ1Zy4NCj4gDQo+IFNlcnZpY2UgYW5k IHJlcG9ydGluZyBwYXNzd29yZHMgYXJlIG5vdCBzZWNyZXQuICBJIGNhbiBpc29sYXRlIERFViAv UUEgLyBQcm9kdWN0aW9uIGJ1dCBpdCBkb2Vzbid0IHByb3RlY3QgdGhlIHNjaGVtYS4NCj4gDQo+ IGRidW5sb2FkIGFuZCBjb3B5ZGIgZmlsZXMgYXJlIGluIHBsYWluIHRleHQuICBQYXNzd29yZHMg YXJlIGVuY3J5cHRlZCBidXQgbm90IHNjaGVtYSAvIHByb2NlZHVyYWwgY29kZS4NCj4gDQo+IFdl YiBhbmQgLm5ldCBjb25maWcgZmlsZXMgaGF2ZSBhIERTTiB3aGljaCBJIGJlbGlldmUgY2FuIGJl IGRlY3J5cHRlZC4gDQo+IA0KPiANCj4gT24gMS8wNS8yMDIxIDEwOjMxIHBtLCBSb3kgSGFubiB3 cm90ZToNCj4gDQo+PiBQYXVsIFdoaXRlIHdyb3RlOg0KPj4gDQo+PiANCj4+PiBJIHdvdWxkIGxp a2UgdG8gaGlkZSBvciBlbmNyeXB0IHRoZSBzb3VyY2UgY29kZSBmb3IgYSBzcGVjaWZpYyANCj4+ PiBkYXRhYmFzZSBwcm9jZWR1cmUuDQo+Pj4gDQo+PiBUbyBzdG9wIG15c2VsZiBmdXNzaW5nIHdp dGggdGhpcyBsb29zZSB0b290aCBJIGFtIGdvaW5nIHRvIHB1YmxpY2x5IA0KPj4gZGVjbGFyZSBk ZWZlYXQgc28gSSBjYW4gbW92ZSBvbi4gSSBkb24ndCBzZWUgYSB3YXkgdG8gZG8gaXQuDQo+PiBF dmVyeXRoaW5nIEkgdGhvdWdodCBvZiBpcyBlYXNpbHkgc3VidmVydGVkIG9yIGJyZWFrcyBJbmdy ZXMgb3IgDQo+PiAoc2hvdWxkKSBpbnZhbGlkYXRlIHlvdXIgc3VwcG9ydCBhZ3JlZW1lbnQuDQo+ PiANCj4+IFJveQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IEluZm8taW5ncmVzIG1haWxpbmcgbGlzdA0KPj4gDQo+PiBJbmZvLWluZ3Jlc0Bs aXN0cy5wbGFuZXRpbmdyZXMub3JnDQo+PiBodHRwczovL2xpc3RzLnBsYW5ldGluZ3Jlcy5vcmcv bWFpbG1hbi9saXN0aW5mby9pbmZvLWluZ3Jlcw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBJbmZvLWluZ3JlcyBtYWlsaW5nIGxpc3QNCj4gSW5m by1pbmdyZXNAbGlzdHMucGxhbmV0aW5ncmVzLm9yZw0KPiBodHRwczovL2xpc3RzLnBsYW5ldGlu Z3Jlcy5vcmcvbWFpbG1hbi9saXN0aW5mby9pbmZvLWluZ3Jlcw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSW5mby1pbmdyZXMgbWFpbGluZyBsaXN0 DQpJbmZvLWluZ3Jlc0BsaXN0cy5wbGFuZXRpbmdyZXMub3JnDQpodHRwczovL2xpc3RzLnBsYW5l dGluZ3Jlcy5vcmcvbWFpbG1hbi9saXN0aW5mby9pbmZvLWluZ3Jlcw0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)