[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference csc32::consolemanager

Title:POLYCENTER Console Manager
Notice:Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:CSC32::BUTTERWORTH
Created:Thu Aug 06 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1541
Total number of notes:6564

854.0. "Serious nonpriv-user problem!" by UTRTSC::WIJKAMP (One day, you won't drink beer, you'll drink GROLSCH) Thu Jul 06 1995 13:50



    Hello,


    Customer found the following problem:

    He is installing a new PCM-console system, to take over his
    VCS system, that is used for their production cluster.

    They are testing now. I supplied them with V1.6 last week,
    because they ran into a number of problems in V1.5.

    They went on testing, and are very happy with the fixes! 

    BUT: During test, they found out that an unprivileged user
    with TMPMBX and NETMBX can start C3, and not only that:

    This user can start the editor, and change all kind of
    things.

    This user DEFINITLY has no priv's, and is NOT AT ALL
    mentioned as PCM user!!!

    Since this customer is a Bank, and security is top of the
    list, he has some headaches now, and is very concerned about this.
    They are still testing, but they want a fix before this goes
    into production.

    I can easily reproduce this.
    C3 window and eventlist can be displayed. (Some systems are
    shown, and some are not.)
    Editor can be started (from C3 and with $ CONSOLE EDIT.) Some
    functions are grayed out, but others work.
    An exit from the editor makes the changes. (I only tested a
    change to an event.)


    Any help, advise (and FIX) would be greatly appreciated!

    Thanks in advance,


    Ren� Wijkamp,

    MCS, OSS The Netherlands.
T.RTitleUserPersonal
Name		DateLines
854.1Yes, a bugZENDIA::DBIGELOWInnovate, Integrate, EvaporateThu Jul 06 1995 19:079
    Yes, this looks like a bug. You can definately edit the PCM database
    if you are not a PCM user. The way that it used to work is that 
    you had to be logged into the system account or root (Unix), so it
    looks like we've intriduced a new bug with v1.6. 
    
    There should be a new MUP kit for the V1.6 kit which we hope to have
    ready with a few weeks.
    
    Dave
854.2OPG::PHILIPAnd through the square window...Thu Jul 06 1995 19:388
Ren�

  I have just fixed this, as Dave says, this will be available
  in the MUP kit which should be ready for testing next week.

Cheers,
phil
854.3Still some 'minor' problems.54687::WIJKAMPOne day, you won't drink beer, you'll drink GROLSCHMon Jul 31 1995 11:5663
    
    
    Hello,
    
    
    After installing the ECO V1 for V1.6, the customer reports stil some
    'small' security problems.
    
    First:
    
    When the nice nonprivilegde and unmentioned user starts up a C3 he
    receives a nearly empty C3 window, with only lines and periferals and
    no systems in sight.
    His EXIT and QUIT are grayed out. But he can do a SAVE or SAVE as ...
    from the options menu, and so can create a new version of 
    console$user_defaults:CONSOLE$C3.DAT. (He even owns the file.) Since
    this is in a common directory this is not pleasant. The next 'prived'
    user receives an empty C3. So a totaly nonprived user can distroy my
    hardwork designed C3. 
    Onother nasty point is that, since EXIT and QUIT do not work, the only
    'exit' that is possible is CTRL-Y. (And since I always start C3 as
    detached process only a STOP/ID will do.)
    
    Second:
    
    When I do an EXPORT from the editor, a *.port file is created.
    When I have users that have no access at all, they are mentioned as
    follows in the *.port file:
    
    
    DELETE_USER:
        NAME: Duck
    END:
    
    ADD_USER:
        NAME: Duck
        INFO: Duck test voor Ren�.
        MAY_STARTUP: N
        MAY_RECONFIGURE: N
        MAY_UNLOCK: N
        MAY_BREAK: N
        MAY_SHUTDOWN: N
        MAY_ARCHIVE: N
        MAY_EXITC3: N
        MAY_EDIT_CFG: N
        MAY_ACCESS_ALL_SYSTEMS: Y
        MAY_ACCESS_ALL_GROUPS: Y
    END:                                                              
    
    The missing item is MAY_EDIT_C3 (or some 'symbol' like that).
    When doing an import from this file, this user all a sudden has the
    right to EDIT C3. 
    
    Customer has taken measures to minimize the effect off these unwanted
    sideeffects, but like to see a fix.
    
    
    Thanks again for your answers/help/replies ect.   in advance again.
    
    Greetings,
    
    Ren�.
854.429067::BUTTERWORTHGun Control is a steady hand.Mon Jul 31 1995 15:1324
    >  console$user_defaults:CONSOLE$C3.DAT. (He even owns the file.) Since
    >  this is in a common directory this is not pleasant. The next
    >'prived' user receives an empty C3. So a totaly nonprived user can distroy
    > my hardwork designed C3.
    
    I have two suggestion to workaorund this problem:
    
    Dissallow write access to the CONSOLE$USER_DEFAULTS directory using a
    rights-id or UIC based protection.
    
    Define the CONSOLE$USER_DEFAULTS to be a search list that has both a
    common directory and a user specific directory in the equivalence
    names and disallow write access to the common directory for these
    users. 
    
    The fix for the C3 will be to stipple out the "Save" button when a user
    doesn't have the priviledge to edit the C3. If they aren't allowed to
    edit it they shouldn't be allowed to save it either.
    
    I would open a priority 3 IPMT so that the problem is officially
    reported.
    
    Regards,
       Dan
854.5Protection does not allow access.54687::WIJKAMPOne day, you won't drink beer, you'll drink GROLSCHTue Aug 01 1995 04:4847
When the user would have had write access to the
console$user_defaults directory, and read/write access to
CONSOLE$C3.DAT, than you could expect that he had 
the possibility to read and write this file, and I 
probably would not have entered reply .3.

The Problem is: (I agree that I did not state this clearly before.)

This USER (UIC = [123,456]) has no rights to the file, and only
has E access to the directory.

$ dir console$user_defaults/sec

Directory CONSOLE$ROOT:[C3]

CONSOLE$C3.DAT;11    [SYSTEM]                         (RWED,RWED,,)

$ sh log console$root
   "CONSOLE$ROOT" = "$1$DKA100:[CONSOLE.]" (CONSOLE$LOGICAL_NAMES)
$ dir/sec $1$DKA100:[CONSOLE]c3

Directory $1$DKA100:[CONSOLE]

C3.DIR;1             [SYSTEM]                         (RWE,RWE,RE,E)
                                                                              
So somehow PCM break's 'normal' protection rules.

For my customer this problem is not so big anymore. I convinced 
him to add all users to PCM. (Not so many on a CONSOLE-system.)
And after the ECO this stops the access for the users without 
access granted.

BUT: Now we have the following side-effect.

During the tests (he is still testing), he did an export with
al his user added, and a number off them with no access at all.
After the IMPORT again, all a sudden this users without ANY access
where allowed to edit C3 again. (All the time this C3.)
He finds this not acceptable. He can't trust the behaviour of 
export/import, and has to check things over again. 

So the main point is that he still has no 'waterproof' way to 
stop users that should not have any access.

Greetings,

Ren�.
854.629067::BUTTERWORTHGun Control is a steady hand.Tue Aug 01 1995 15:4755
>When the user would have had write access to the
>console$user_defaults directory, and read/write access to
>CONSOLE$C3.DAT, than you could expect that he had 
>the possibility to read and write this file, and I 
>probably would not have entered reply .3.
    
    Maybe. I took your note to read that "a user should not be able to
    modify/destroy a common CONSOLE$C3.DAT file" and basically I was
    agreeing you. I think it should be fixed. You asked for a workaround
    and I came up with one.

>The Problem is: (I agree that I did not state this clearly before.)

>This USER (UIC = [123,456]) has no rights to the file, and only
>has E access to the directory.

>$ dir console$user_defaults/sec

>Directory CONSOLE$ROOT:[C3]

>CONSOLE$C3.DAT;11    [SYSTEM]                         (RWED,RWED,,)

>$ sh log console$root
>   "CONSOLE$ROOT" = "$1$DKA100:[CONSOLE.]" (CONSOLE$LOGICAL_NAMES)
>$ dir/sec $1$DKA100:[CONSOLE]c3

>Directory $1$DKA100:[CONSOLE]

>C3.DIR;1             [SYSTEM]                         (RWE,RWE,RE,E)
                                                                              
>So somehow PCM break's 'normal' protection rules.
    
    The C3 is INSTALL'ed with SYSPRV which so it used the SYSTEM protection 
    field to gain access to the file.

>For my customer this problem is not so big anymore. I convinced 
>him to add all users to PCM. (Not so many on a CONSOLE-system.)
>And after the ECO this stops the access for the users without 
>access granted.

>BUT: Now we have the following side-effect.

>During the tests (he is still testing), he did an export with
>al his user added, and a number off them with no access at all.
>After the IMPORT again, all a sudden this users without ANY access
>where allowed to edit C3 again. (All the time this C3.)
>He finds this not acceptable. He can't trust the behaviour of 
>export/import, and has to check things over again. 
    
    Obviously this is a bug and needs to be fixed. Please log an IPMT so
    that it gets tracked and fixed.

    
    Regs,
       Dan
854.7An IPMT it will be.54687::WIJKAMPOne day, you won't drink beer, you'll drink GROLSCHWed Aug 02 1995 09:0622
    
    Dan,
    
    When I re-read my reply, I'm aware of the unpleasant undertone in
    my reply .5. I'm sorry for that, it was not mentioned to sound like
    that.  The problem with this kind of problems is very often, that you
    looked into it for a while, you check a number of possible causes, and
    can't find a reason/solution ect.
    When you enter a note, you're 3 steps ahead, and you forget to mention
    that you checked the first 'obvious' things.
    You hope to get a reply, and often you get the obvious one 
    that you have forgotten, so I think you're right to give a
    workaround/advise that seems obvious, when I did not mention that I
    checked that. (I have the feeling I start to be a philsopher. -) )
    
    Thanks for your replies.
    I agree with you, and raise an IPMT case.
    
    Greetings,
    
    Ren�.