Date:         Tue, 19 Dec 1995 09:46:15 -0500
Reply-To:     The NOMAD2 Discussion List
Sender:       The NOMAD2 Discussion List
From:         "Darrell R. Pitzer"
Subject:      NO SUBJECT

From:  Darrell R. Pitzer
Subject: Securing a db against knowledgable opponent

Regarding the post about securing a shared database from a knowledgeable
opponent (original post omitted to save space), I think that David TvE et al
have outlined a number of good ideas. Here are a couple more:

   (a) You CAN provide userid based security in the profile. The database
       profile will be executed on the server, so hide it (e.g., make it
       an A0 file if you are on VM). In the database, put in a table that
       is keyed on userid (or userid & node if you are using NOMAD's
       remote shared database feature). Add some items to that table that
       tell you what to do if a userid tries to connect to the database.
       (e.g., here, we have an item that says who can/cannot change the
       userid/permission table ... if they can't, we do a MODIFY ACCESS
       READONLY on that table).

       In the profile, user &&Userid to look up the user in the permission
       table. If it is the "bad actor", deny access (in TRANS mode, do a
       DBCLEAR and EXIT), or if he/she has to have access, print a message
       saying that access is being logged, etc.

       If this person has to have access to the database, and you are
       worried that they might see the userid/permission table, then
       REMOVE that table after you've looked them up & set up security
       based on their userid.

       I've not found a way around a database profile security check (on
       VM). I'm sure that Thomson would be interested if you found a way.

   (b) Have your database profile activate the application, and after
       the application ends, have the database profile remove the
       CHANGE/INSERT/REPLACE/DELETE & SLIST commands. Also, do a DBCLEAR to
       keep them from seeing the database. If they need access in interactive
       NOMAD for reporting, you could do a MODIFY ACCESS READONLY on all
       segments just to keep them from finding a way to change things. E.g.,

            call MAINPROG;   !-- Invokes your menu application --!
            trans;
            remove prescan commands change replace insert delete slist;
            modify MASTER1 access readonly;
            modify MASTER2 access readonly;
            ...etc....
            untrans;

       You could add a check on a field from the permission table if you
       need to let certain userids (e.g., your own) still have access
       after the application (e.g., add an IF block around the TRANS/UNTRANS
       statements above:   IF &PERM_DBA <> 'Y' THEN DO;)

       There isn't a way to activate a shared database without going
       through the profile, and if your profile changes the NOMAD
       environment as above, they can't do anything nasty or even see
       what the database looks like (by REMOVE on the SLIST command).

Regards,
Darrell Pitzer, Exxon R&D, (504) 359-1130, Darrell.R.Pitzer@Exxon.Sprint.COM
back to index