Date: Tue, 19 Dec 1995 07:06:16 -0700
Reply-To: The NOMAD2 Discussion List
Sender: The NOMAD2 Discussion List
From: Michael Dow
Subject: Re: Securing a db against knowledgable opponent
In-Reply-To: "Mail dated 95/12/19 03:18:16 UT from (NOMAD2-L) The NOMAD2
Discussion List"
I would also suggest limiting those who can access the SYSPASS
via a table-method security flag... I have used this quite often
and have had passed on to me (via third party) the frustration
of thwarted security pirates.
Use ACF security... Don't allow people to 'read' your procedures..
Only Execute... You could even use &PROCEDUREMODE (or something
like that? :-)) to force all procesures to be executed from a
particular disk... I haven't had to use that one though.
There are many ways to get around all of the problems you mention..
Trust me, security isn't as nasty as you think...
Michael R. Dow
Motorola/Austin I.S.
>___Original Letter _______________________________________
>Date: 18 Dec 1995 17:51:49 -0700
>Sender: The NOMAD2 Discussion List (NOMAD2-L)
>From: David Thornewill (TTG242)
>To: Multiple recipients of list NOMAD2-L (NOMAD2-L)
>Reply-To: The NOMAD2 Discussion List (NOMAD2-L)
>Subject: Re: Securing a db against knowledgable opponent
>
>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 !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>___End of Original Letter_________________________________
back to index