Conference csc32::consolemanager

Anna,

  What you have read in the User guide is all there is.

  Were you looking for something specific? Have we forgotten
  something you or your customer requires?

Cheers,
Phil

    Phil,
    
    let me ask the question in different fashion.
    
    The PCM is composed by processes and data file. There are two way to
    protect the software and the data:
    
    1. Using the standard features for security provided by the operating 
    system (file protection, for istance).
    
    2. Defining the user name in the profile database.
    
    Are these security features enough to protect the software/product and
    the data by any intrusion?
    
    At the moment I have no specific requirements from the customer. My
    question was only to get more information as possible about the
    product.
    
    Thanks.
    
    							Anna
                                                            

On UNIX

The files used by CM are granted access only to root for write as are the
sockets used for IPC.

In order that the normal user may access the files and sockets protected from
him the console image is setuid. This image in tern calls the images required to
perform the CM functions.

No shell escapes exist as such in any of the CM functions which means we are
within the security requirements.

VMS.

We again restrict file and mailbox access and use Installed images to provide
the required privs.


In both cases the overlaying security is provided by the CM database in that the 
CM images each check the user privs before allowing the relevant function to be
called.

Hope that is clearer.

Cheers Simon...

I just had a look at the User Guide to find out details about security, access
restriction etc.

I found that the access restrictions (e.g. may transmit break signal, may
archive console data, ...) are only settable per user and not per system/group.

Did I miss something ?  Though I don't currently have an immediate request, I
can think of the following situation:

Systems are divided into two groups with a manager (group) assigned to each
group of systems. Each manager group should have full access to "their" group of
systems, with restricted (monitoring) access to the other group of systems. As I
interprete the User Guide, this is not possible - correct ?

Thanks for your help,
Hans.

Hans,

>>I found that the access restrictions (e.g. may transmit break signal, may
>>archive console data, ...) are only settable per user and not per system/group.
>>
>>Did I miss something ?  Though I don't currently have an immediate request, I
>>can think of the following situation:

  You didnt miss anything. Giving a system BREAK privilege would not be the
  correct thing to do as it would mean ANY user with access to the system would
  have the ability to send the BREAK signal.

>>Systems are divided into two groups with a manager (group) assigned to each
>>group of systems. Each manager group should have full access to "their" group of
>>systems, with restricted (monitoring) access to the other group of systems. As I
>>interprete the User Guide, this is not possible - correct ?

  You are correct, this is not possible in V1.1

  User groups are not something we thought of, however, if you submit a Phase 0
  request when Phase 0 is announced for V1.1+, we will certainly consider
  implementing such a feature.

Cheers,
Phil

Phil,

thanks for the speedy reply !

I'm afraid I did not express my question clearly enough. I'll use an example to
illustrate my idea:

I have two groups of systems: "Production" and "Development". For simplicity of
the example, there are two system managers: J_DOE who is responsible for the
"Production" group, and J_SMITH who is responsible for the "Development" group.
What I am thinking of is the following setup:

J_DOE has full access to "his" production group, and monitoring access to the
development group.

J_SMITH has full access to "his" development group, and monitoring access to the
production group.

I did not want to enable BREAK simply on the system level, but on a per user/per
system level, i.e. allow a specific user different level of access to different
(groups of) systems.

BTW, the concept of user groups which you found in my request seems to be a good
one as well, even if my suggestion wasn't meant to go that far ;-)

Cheers,
Hans.

Hans,

  Well that certainly clarifies things, as well as making it more
  difficult for us to implement!! My request still stands though,
  can you please submit a formal Phase 0 request when we announce
  Phase 0 for V1.2

Cheers,
Phil