>We're looking at the possibility of putting ADSM up for campus-wide work,
>and our security fellow had a few questions:
>
>1)  Is data being shipped by ADSM encrypted in any way?  How about the data
>    being stored?  If not, is this planned for a future release?
>
>2)  Are passwords stored in an encrypted format, or are they "plain text"?
>
>3)  What kind of safeguards are in place to prevent anyone from spoofing
>    a client into thinking that an unauthorized system is actually the
>    server?

To answer your questions:

1.  No, there is no encryption.  However, if you turn on compression, this
provides a cheap form, since someone would have to know the compression scheme
to access the data.  Also, there is no translation from ASCII to EBCIDIC done,
so if you are using a mainframe server, there is another thing to tackle
before the data can be "stolen".

2.  Passwords are not "normally" kept in a display format.  However, there are
several instances where users might do so - fo example, some of the command
interface scripts our users have written have included a password, so that a
user won't be prompted.  This clearly is a security violation.  NetWare
servers will prompt initially for a master userid and password, and then store
this in an excrypted dataset.  This can be turned off, but then the id and
password must be included in the options format.  Most everyone that I have
talked to that does this then uses NetWare facilities to prevent users from
accessing this information. There are probably other issues with passwords on
Unix machines that I can't address due to lack of experience.

3.  I have never thought about the scenario you suggested, but I suppose that
it would be possible.  For example, we use TCP/IP with domain name services
for access for most of our customers.  I suppose someone could come in and
address themselves as the server address if it was down, and then start up as
a server, assuming they had server code available.  A client who was looking
to do a backup (say via a schedule) would then come in and establish a session
with the rogue server, assuming that the schedule name matched.  He would
appear as a new client and then do a full backup, potentially.

We have used the opposite approach as a "feature" to help out some emergency
restores - A client can change the nodename in his DSM.opt, and if he knows
the password for the new node, then come in and restore your data.  This
means that he has breached your password security process, somehow; if he has
gone this far, he could also be doing this from your machine.  I believe that
if you have a dataset with other forms of security activated, then the
information is backed up with it, and subsequently restored, but am not sure,
especially in a Unix environment.


Hope these answers help.  If you have any other questions let me know, either
directly, or though the list server.

Jerry Lawson