Conference azur::mcc

Bob,

Why not make use of the Q_in qualifier. You can pass any
accounting info such as BY account, BY user, By Password
etc. Is there any reason why this would not work?

I agree at present we are not using Q_in for deciding 
how friendly the user messages can be. But nothing
stops the information providers to use Q_in parameter
of the call argument!

- Anil

    I don't understand.
    
    The situation I see is that the system is installed and a NON PRIV
    user is trying to use it and is getting content free error messages
    about things it cannot access. In order to properly correct the problem
    (without, please note, enabling additional privs for the user) one
    needs to know the specific resources that are protected against the
    user.
    
    This could occure as a result of someone accedentally setting the
    protections on some files to the wrong values or perhaps some automated
    proceedure such as generated by an application like INSPECT could have
    changed protections or ACLs.
    
    I don't know what these Q_in's are that you mention.
    
    s/rob

    RE: .*
    
    I think that Rob is approaching the solution to the problem (telling
    people there is a security problem may be a security leak, if you
    tell them too much) from an end user's viewpoint, while Anil is
    approaching the solution to the problem from an implementor's viewpoint.
    
    Colin Strutt gave me an example of this kind of problem by explaining
    to me the VMS Mail problem.  If you try to send mail to someone, and
    the person is not at the node, it displays an error message. How nice
    and user friendly.  However, it is also considered by many to be a
    security loophole.  If you are not supposed to know that a person is
    at a certain node, you have to turn off mail.  Supposedly, someone
    actually figured out the Lee Iacoca was at DECworld in Boston
    (aboard the QEII) by trying to send mail to node::IACOCA (sp?).  When
    it stopped complaining, the individual knew that Lee Iacoca was
    probably somewhere on the ship.  But how could you prevent it?  Always
    send mail? Even if no one is on the other side to recieve it?
    
    The problem is a classic case of conflicting requirements.  User
    Friendliness says, "tell the user as much as possible so they will know
    exactly what the problem is".  Security says, "tell the user as little
    as possible (absolutely nothing being ideal)".
    
    MCC for the most part, relies on the security of the operating system.
    To implement security on a per-entity basis is a difficult problem to
    solve.  We could solve by implementing it in the Management Modules (as
    Anil proposed), or we could solve it by expanding our use of the
    Operating Systems security features, or a combination other system
    features, as Rob proposed.  In the long term, we need an MCC Security
    Model (perhaps even incorporating a Security Manager into MCC). 
    However, in the short term, I think Rob may be on the right track. 
    Isn't there a way in VMS to have Application level ACLs?  Perhaps this
    could dictate the amount of additional information MCC provides to the
    user.
    
    Also, Rob should note that often there is no way for the lower level MCC
    routines to pass the additional information up to the Management
    Modules which call them (we usually only have a CVR to play with), so
    the information being display may be the best we can do anyway.
    
    -Matt.

If this is really a security issue then have the application verify the 
priviledge mask or whatever the equivilent is for the type of operating system
is for MCC is running on. If the user has the appropriate privs (i.e. bypass
for VMS) print out complete error messages including file names.

Gary Thrower
N&SS Network Support
Colorado Springs

    Gary,
    
    Real quick, The last item Matt was saying is better understood when you
    look at the model. A PM makes a request, and an FM or AM responds. If
    the FM/AM has a problem doing something they have two choices, return
    an exception or a CVR. If the error happens when calling an MCC service
    (like open a MIR) then the routine called can only return a CVR (one
    message). This is very limiting. Because of this it is not really
    possible to return two messages, one being the standard vague one you
    get already, and the second being a more explicit one. We can't
    do as many other applications do and simply signal it to the display.
    The problems there are you don't know what kind of display it is
    (windows of command line) and doing that doesn't not interoperate
    with the PMs (which own the display at run time).
    
    This is currently a problem in message passing, but right now I
    know of no simple solution.

    Re: .4
    
    It isn't an acceptible solution to grant privs to a normally nonpriv
    user in order to diagnose a problem. In fact, it may not be practical
    to even exit the image let alone the process in order to pick up the
    privs.
    
    re: .5
    
    I agree Jill that in some cases the info is simply not available but
    in the cases where MCC knows what it was trying to do but because of
    SQL requiments is surpressing some info, it would be good if there
    was a way for an authorized person (such as the system manager) to
    enable the extra info.
    
    s/rob
    

It is  not  the job of applications to increase the security provided by the
base  system.   At  least  not  in  the  sense  of deliberately hiding error
information  (which  is  a  controversial and problematic security technique
anyway).   The  only  justification is if the application has more privilege
than the user and hence knows more information than the user is permitted to
know.

If MCC  can't open some file it needs to get at (the data dictionary say) it
is  acting,  at that time, as a dumb application using the user's privileges
and  access  rights.   If  VMS  (or  ULTRIX)  chooses  to  return MCC a nice
descriptive message telling you exactly what went wrong and why and what the
system  password  is so that you can fix it (!) then that is what MCC should
display!  If the customer wants better security than that he should complain
to  the  operating  system  group,  not  ask  MCC  to  hide the information!
Otherwise  the  user  can  still  poke around and get that information using
DIRECTORY, TYPE etc.  This sort of security belongs in the trusted kernel.

There may be technical reasons to explain why, currently, the information is
lost.   Those  should be worked on and as soon as they can be fixed the full
message  should be displayed.  I have wasted a lot of time over the last few
months getting DECplan to work: a lot of that wasted time is because DECplan
can't  display the RDB error it gets and RDB can't return the underlying VMS
error  (e.g.   device  full or insufficient quota)! Losing error detail is a
serious problem.

Graham

P.S.  in  the case where MCC is acting as the trusted kernel (e.g.  security
of  information  kept  by AM's) there is, of course, sense in discussing how
much  information  should be returned.  However, this discussion seems to be
about objects protected by other security systems (e.g. VMS).