ADSM-L

Security hole - WAS: HELP!!! Backup archive nodes with admin pri viledges

1999-07-16 10:29:45
Subject: Security hole - WAS: HELP!!! Backup archive nodes with admin pri viledges
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Fri, 16 Jul 1999 10:29:45 -0400
I forget which maintenance level started this "feature", but whenever you
register a client now, the default is to also register an administrative ID
with the CLIENT OWNER privelege.  It is a privilege which enables the use of
the new web client, which is a browser interface, instead or in addition to
the client GUI interface for backup & archive functions..

There is a parameter you can specify (USERID=NONE) that will prevent the
creation of the admin id when the node is registered.

There are 3 implications:

*       By creation of this admin id, the client's human user is allowed to
use the web client, which is a browser interface, to do adsm functions
(backup, archive, etc.) instead of or in addition to, the GUI interface.

*       Any Joe Blow user with the "CLIENT OWNER" privilege, in addition to
using the web client on his own machine, now also has query authority
against your ADSM data base.  If your data base is large, a badly-designed
SQL query can bring your ADSM server to its knees.

*       That same Joe Blow user can now query the ADSM data base to find out
information about any OTHER user's files, such as a list of everything
another user has backed up, via an SQL query.


This is a VERY bad design.  I use the word "Design" loosely, because it
obviously was a very badly-thought-out, or un-thought-out move on the
developer's part.

This opens up a very large integrity exposure, and what is really a security
exposure.   In an environment with classified data, there is NO
JUSTIFICATION for any user being able to query the data base for information
about another user.

It is really stupid for ADSM to compromise what is otherwise an unusually
robust security design in order to implement a quickie web interface.

Now of course, you can just refuse to set up the CLIENT OWNER admin id, and
disallow use of the web interface to the owner of the machine.

But for installations that are trying to work towards standardizing on a
browser user interface (which should include ADSM/IBM/Tivoli), this is just
creating a problem where none need exist.

And the reason I'm really ticked about this is that we have ADSM on a
classified network, and I tried to get a solution to this issue by going
through IBMlink IBM support, and instead of saying "oops, we'll work on
that", the response to my problem was "working as designed".  They won't
even consider it a problem.

This type of answer really sucks.  When the designers open up a
security/integrity problem by adding new code, they should own up to it, and
fix it.  I get really tired of the "working as designed" runaround.


My opinions and nobody else's,

Wanda Prather


> -----Original Message-----
> From: Tefo Moreki [SMTP:TEFOM AT ZA.IBM DOT COM]
> Sent: Friday, July 16, 1999 7:25 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      HELP!!! Backup archive nodes with admin priviledges
>
> Lately I realised that when querry administrators, there are strange new
> entries in my administrators list. The command 'q admin' lists all
> administrators which I have defined, however, some backup archive clients
> are also listed in the administrators list. These B/A clients have a
> priviledge class of 'client owner' and when I logged on as one of these
> B/A
> clients I realised that I could execute admin querry commands but could
> not
> update anything.
>
> Would any of you know how this came about?
> Is this a special feature in the new level of ADSM? (I am running 3.1.2.20
> on MVS)
> What are the implications of having B/A client with admin priviledges?
>
> Thanx in advance.
>
> Tefo
<Prev in Thread] Current Thread [Next in Thread>
  • Security hole - WAS: HELP!!! Backup archive nodes with admin pri viledges, Prather, Wanda <=