Date:         Mon, 18 Dec 1995 17:51:49 -0700
Reply-To:     The NOMAD2 Discussion List
Sender:       The NOMAD2 Discussion List
From:         David Thornewill von Essen
Subject:      Re: Securing a db against knowledgable opponent
In-Reply-To:  <30D5F759@gegpo1.geg.mot.com> from "Walters Chris" at Dec 18,
              95 04:15:00 pm

Seems like you have a personnel problem.  But anyway here are
some thoughts.

1. Use &PWNUMBER and don't use DBAPASS in any procedure.
2. Turn off interactive mode except to certain (your) admin accounts.
3. Change the item names to something only you know, e.g. a '__'
         prefix, and turn off the SLIST command, if the attacker doesn't
         know the item names the contents are hard to change.
4. Log all changes, and let the attacker know they are being logged.
5. In your procedures create a lock in a table known only to
         yourself and check it using a UPROC before doing any change
         on the database.

There are probably many other schemes, but these should keep the
attacker at bay for a while.  Also, as with all security schemes,
the method can be public, but they should still defeat the attacker.
i.e. security through obscurity is oxymoronic.

Regards,
David TvE

According to Walters Chris:
>
> OK NOMADers, here's a problem
>
> I am the new system administrator for a shared db under VM. I need to
> protect the db from attacks by the previous sysadmin, who knows NOMAD pretty
> well. Users of the system (who have the DBAPASSword) ask him to write
> programs that change the db contents. My menu-driven system also has options
> that change the db contents (using CHANGE, INSERT, REPLACE, DELETE
> commands).
>
> I can't use a REMOVE in the db profile to remove the C/I/R/D commands
> because my menus use them too.
>
> I tried renaming the db, PRESCANing all procedures that do a DA XXXX OWNERID
> YYYYY and hiding the source code, but DA XXXX OWNERID YYYYY is still visible
> in the N2PROC. So he can get the database name.
>
> I tried moving all procedures containing DA XXXX OWNERID YYYYY  from the
> public 192 disk to the 191 disk of the owner account to hide them, but the
> procedures can't be found by VM when called. Seems like you can't execute
> code stored on the same disk as the shared db, probably because you don't
> access that disk directly. So I can't hide them either.
>
> No telling what accounts these rougue procedures live on so can't put a
> screen on &userid in place in the db profile.
>
> So, any suggestions? Please email replys directly to me - he may very well
> be on this list!
>
> Chris Walters
> CIDM, Motorola GSTG
> p23610@email.mot.com
>


--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! David Thornewill von Essen               LATG MRPII Program Manager !
! Motorola LATG Operations                     Maildrop: AZ34 / EL557 !
! Tempe, AZ-85284                                 fax: (602) 413-5566 !
! email: ttg242@email.sps.mot.com                 tel: (602) 413-6051 !
+---------------------------------------------------------------------+
!      'At times we must engage an act of faith that key              !
!       things are doable that are not provable' -- Bob Galvin        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
back to index