Conference iosg::all-in-1_v30

    I doubt very much whether there are any articles outlining security
    procedures within ALL-IN-1. What specific details is the customer
    interested in?  ALL-IN-1 is, after all, an application running under
    VMS, so it's the normal VMS system security that forms the cornerstone
    of any security measures that ALL-IN-1 requires.  It's worth noting at
    this point that ALL-IN-1 V3.0 makes much better use of things like VMS
    identifiers and rights, and that captive accounts have been made fairly
    watertight.
    
    Tony

    Also, v3.0 will (optionally) record all system admin operations which
    affect accounts (creation, deletion, etc). Auditors tend to like this
    kind of thing, which is why we added the feature.
    
    D.

    Hi --
    
    I've been asked to do a security evaluation on an ALL-IN-1
    installation, and I've been out of the ALL-IN-1 arena for about two or
    three years.  The type of evaluation is *very* specific -- they're
    concerned about the ability of captive users to access in any way
    (either retrieving or depositing data, files, etc.) on another node in
    the network which does not run ALL-IN-1.  Mailbus/Message Router is not
    used on either system.  A further complication is that the non-ALL-IN-1
    system has received a poor rating on its security audit -- it's a
    pretty wide open system.  The auditors are loathe to grant us network
    access to it unless we can demonstrate that we've prevented our users
    from messing with it over the network.  (Yes, we suffer for the error
    of their ways.)
    
    So I'm interested in finding out any ALL-IN-1 functions that could have
    any impact over a network on a non-ALL-IN-1 system.  Obviously,
    Document Transfer and Electronic Mail (via SPECIAL.COM) come to mind. 
    What others might there be?
    
    I plan to review all the functions, but my customer needs buyoff from
    their internal auditors before they can go into production -- cutover
    is scheduled for June 1.  You can see that time is of the essence so
    your input could help me meet that deadline.
    
    The customer is on V2.4 and does not intend to upgrade in the immediate
    future so if there are measures we should take to plug holes in captive
    user accounts, I'd appreciate pointers on them, too.
    
    Finally, they're using integrated WordPerfect.  I'm not at all familiar
    with its features.  My customer has told me that it has an include-file 
    functionality that could potentially pull a file over the network. 
    Does anyone know if this is true -- and if it is, if it would be simple
    or hard to trap such requests and head them off at the pass.
    
    Thanks much for your input,
    
    Joel
                   

    Would it make sense to not give the ALL-IN-1 users the NETMBX
    privilege?  It doesn't sound like they would need it.

    Security is very much tightened in ALL-IN-1 V3.0 over V2.4 so moving to
    V3.0 would be a very good idea.  We probably shouldn't discuss too many
    of the gory details here as policy is to keep security discussions as
    vague as possible so as to not spread the knowledge of 'features' too
    far and wide.  (The moderators will appreciate all the gentle writers
    in this conference from debating this point here, thanks.)

    The most visible area of improvement is in keeping users from executing
    their own code and getting to DCL and ALL-IN-1 functions.  There are a
    few tools available in DECUS to hack in some crude checks for this in
    V2.x but V3 is the best choice, by far.

    Good luck,
    don

    So help me here...
    
    These people have got a very insecure system, and they want you to
    protect their system from being sc***ed up!!
    
    Seriously (??) what sort of legal access are yoou going to do to this
    machine (perhaps I should start calling it a leaky sieve??!) and what
    sort of access do they want to stop you doing?
    
    Obviously you can DT SV across the network if the remote system is
    insecure. GOLD/Write out of the editor and Print to File gives you the
    chance to do this too. Simon says there are some ways to do it from CM
    too.
    
    You also need to take the steps that Don said we wouldn't talk about in
    .-1 to stop them getting to DCL too.
    
    Not feeling very positive about this,
    
    Yours sympathetically,
    
    Graham

    I agree with Graham - if they're worried about access to their insecure
    system, they should improve its security (it's easy enough to configure
    a system to disallow ALL remote file access to it, if required - this
    is a DECnet setup thing).
    
    D.

    You're absolutely right -- the owner of the other VAX should secure it.
    They're in the process of doing that (or so they tell me -- I only came 
    on board yesterday).  The problem here is time frame.  My group needs
    to come on line June 1; the other VAX has production data which we need
    to access through sanctioned channels; the position of the internal
    auditors is that letting us on the net with the other system before they 
    clean up their act just provides one more hole through which the 
    integrity of that system can leak.  The flag was raised here because one 
    of our power users used Document Transfer to suck over something he was 
    supposed to get thru bureaucratic channels.  So we need to reassure
    them that we've prevented our users from doing such things in the
    future if we want to interface with their machine.
    
    If need be, we'll just shut down the network on our side except for a
    file transfer our application needs to do in the middle of the night. 
    We're just trying to avoid such a sledge-hammer approach because our
    users do like to do things like send mail to VMS mail users on the
    other side.
    
    Anyway, thanks for the input thus far.  If anything else occurs to you,
    I'm open to hearing it.
    
    Joel

From .3

>    concerned about the ability of captive users to access in any way
>    (either retrieving or depositing data, files, etc.) on another node 
>    in the network which does not run ALL-IN-1.

From .7

>    The problem here is time frame.  My group needs to come on line June 
>    1; the other VAX has production data which we need to access through 
>    sanctioned channels;

Which will it be.  Do you want users to be able to access data across the
network or not.  If the answer is, "there is some data we want users
to access and other data we don't want them to access," (which is what
it sounds like to me) then the decision will have to be made and enforced
at the source of the data (i.e., file protection).

Also from .7

>    We're just trying to avoid such a sledge-hammer approach because our
>    users do like to do things like send mail to VMS mail users on the
>    other side.
 
They're concerned about users' being able to deposit files on the other
machine but want to preserve the ability to send mail to that machine?  
What is mail if it is not a file?  Again, if there are certain directories
into which the users should not be able to deposit something, then these
directories will need to be protected.

I can't imagine how ALL-IN-1 (or anyother application) on one machine 
can compensate for the lack of security on another system.

With this and 12� other opinions you can buy a cup of coffee.

Joe

    re .8
    
> Which will it be.  Do you want users to be able to access data across the
> network or not.  If the answer is, "there is some data we want users
> to access and other data we don't want them to access," (which is what
> it sounds like to me) then the decision will have to be made and enforced
> at the source of the data (i.e., file protection).
    
    Yes, the ultimate goal is to allow users access to some data and not to
    other.  Howver, the customer is somewhat naive technically regarding
    ALL-IN-1 and would like a laundry list of all the ways users could
    touch another machine over the network.  Then they will go through the
    list and say, "Yes, this function is fine -- no threat there," or "No,
    we don't want users to be able to do that."
    
> They're concerned about users' being able to deposit files on the other
> machine but want to preserve the ability to send mail to that machine?  
> What is mail if it is not a file?  
    
    Well, yes, but there is a difference between someone sending VMS mail
    to another user and someone depositing bogus data where it shouldn't
    be.  Those distinctions are part of the review to take place.
    
> Again, if there are certain directories into which the users should not 
> be able to deposit something, then these directories will need to be
> protected. 
    
    Everyone agrees the other system needs to clean up its act including
    the owners of the other system.  However, that's not going to happen
    before our deadline -- it is not in our control.  We do control how we
    allow our users to relate to that machine.  It doesn't strike me as
    unreasonable to try to block users on our end from doing particular
    functions that are deemed undesirable in the present environment while
    allowing those that are not.  In a perfect world, we wouldn't even have
    to consider this, but it's not perfect here so I'm trying to help them
    with a workaround.  I hope we can avoid going down a rathole of what
    the other system should do -- because you're right so there's no need
    to argue the point -- it's just not reality today.
    
    Thanks,  Joel

    I would guess that you'd be able to log onto the other system and fix
    up its security in less time than it would take you to do all the
    necessary customisations to ALL-IN-1 (and local VMS!) to stop the
    remote access.
    
    IM(H)O,
    
    Graham
    
    PS Saw your mail, I'll get to it later...

    
    	Come on guys, get real, we can all see where this SHOULD be done,
    	but that is not what this caller is asking for, so lets stop
    	discussing it.
    
    	I think the idea of removing NETMBX is the right general direction
    	on this one. Trying to think of all the possible ways a user could
    	access the net is too hard - you're going to miss one. If the users
    	need SOME NETMBX, then maybe you could install the bits that need
    	it with the NETMBX priv.
    
    	Obviously if you want to connect this system to the net then
    	removing NETMBX from all your users is no good, otherwise why
    	connect it in the first place?!
    
    	Another idea would be to have captive accounts and customise off
    	"dangerous" options, but this is more error prone as you could,
    	for example, access the net from within an editor. You could maybe
    	remove NETMBX from all accounts except one, and have that account
    	set up to do JUST the thingy that needs the NETMBX.
    
    	If the data that you want to access can be copied to your system,
    	how about getting the other system (the insecure one) to "PUSH"
    	the data onto some area on your system at regular intervals, and
    	then your users don't need NETMBX to access it?
    
    	A user without NETMBX cannot access the net, except by using an
    	image installed with privs - its fairly bullet proof.
    
    Regards,
    Paul

    Paul's suggestion of removing NETMBX from the user accounts is a good
    one. However, the users will thereby lose the ability to send mail
    EXPRESS (as the Send operation does a DECnet connection to the local
    Message Router). Normal (First_Class) mail will be OK (as long as you
    don't remove NETMBX from the ALLIN1 account!)
    
    There are an awful lot of places where a user can refer to a VMS file,
    for example - DT RV, DT SV, Gold-Get in the editor, etc etc. It would
    be hard work (but possible) to customise those options to reject any
    filespec that contained a double colon. That still wouldn't prevent a
    user with DCL access from assigning a logical to point to a remote
    file, but if they can get DCL access they can use DCL COPY etc to
    access the remote files anyway!
    
    Dave.

This really is an attempt to be helpful, not argumentative.

Yes, you can limit user's access to another system by removing NETMBX
but this won't have the desired results as I understand them.  Those
are:

1) Allow users to access some files on the other system but not others
2) Allow users to write to some directories on the other system but not
   others.

As I see it there are two obvious ways to accomplish this:

1) Maintain a directory of which files a user can read and into which
   directories he can write.  Make all users captive ALL-IN-1 accounts.
   Customize the heck out of ALL-IN-1 to check every place where a 
   user can enter a filename to see if the attempted access is allowed.
   This will take several man-months to implement and not be fool-proof.

2) Clean up the other system.

You said this couldn't happen by the deadline but have you considered
all the options?  Wouldn't it be possible to globaly place an ACL on 
all files on the other system which disallowed access to the default
DECNET account, and then go back and allow read and/or write access
to specific directories and files.  It seems to me that this might not
be that difficult (I've haven't actually tried it).

I don't mean to stifle imaginative conversation and I'm sure I haven't
thought of everything but it seems to me that you're best long-term
AND short-term solution will have to revolve around fixing security on
the other machine.

Good luck,

Joe

    Thanks for all the input.
    
    As I've dug more into this, it's occurred to me, too, that fixing the
    other system would not only be the right thing, but the speedier thing,
    too.  Guess I'll have to see if politics allow it.
    
    In the meantime, I'll be working up an analysis for the customer
    pointing out all the holes we have to plug and how much time it will
    take to plug them.  Since all this work on our side should be a
    temporary fix till the other system gets it together, they may just
    decide to use the sledge hammer approach for the short term.  It
    doesn't make much sense to invest person-months on something we need
    because of artificial, temporary constraints.
    
    The discussion has been helpful.  Thanks again.
    
    Joel