× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Oliver,

Um, we are kind of blending issues here.  I probably should have been more
clear.  If the object itself is secure can control certain aspects.  My
real point it that I would not rely on the restricted user access to
control access to commands.  My example may not be good but let's use
CHGSYSVAL.  A restricted user can't use that.  I believe the default is for
*PUBLIC to *EXCLUDE so that is actually good.  But let's say access to the
command is *USE or something like that.  Using the PC remote command
capability would allow a user to bypass the restricted user attribute.

I think it might be important to differentiate between the security of your
data, objects, and commands if that makes sense.  While your security on
your data may not be perfect (no offense) it isn't terrible.  There is much
worse out there.  FYI - I have a 3rd party package that takes data files to
*PUBLIC *EXCLUDE and then uses a group profile that has *CHANGE.  Well
guess what, most of the users on that system belong to that group.
Horrible security.  Not germane to your issue I just want you to know I'm
not judging your setup.  You are making efforts.

Another point to make is that I believe in using multiple layers to
security.  I want the data secured but I also want to control who has
access to the commands that work with that data or other objects.  There
are probably a 1,000 plus commands on your system (also interesting to note
that access to the CPP can be just as critical).  There are probably a much
higher number of other objects (user profiles, files, outqs, etc.).   While
it may be extra work I would rather control both objects because it is
likely that one or the other is going to missed.  Others may not agree with
this approach but I want the overlap.  It creates more work but I'd rather
have it that way.

Hope that makes sense.  Object security is great....but don't rely on the
restricted user attribute at all.

Michael Crump
Saint-Gobain Containers
1509 S. Macedonia Ave.
Muncie, IN  47302
(765)741-7696
(765)741-7012 f
(800)428-8642

Slow email use this:
mailto:mike.crump@xxxxxxxxxxxxxxxx

Fast email that isn't company standard use this:
mailto:mcrump@xxxxxxxxxxxxxxxx






                                                                                
                                                                
                      oliver.wenzel@xxxxxxxxxxxx                                
                                                                
                      ovartis.com                       To:       Midrange 
Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>               
                                                        cc:                     
                                                                
                      03/20/03 08:47 AM                 bcc:                    
                                                                
                      Please respond to Midrange        Subject:  Re: Security 
questions                                                        
                      Systems Technical                                         
                                                                
                      Discussion                                                
                                                                
                                                                                
                                                                
                                                                                
                                                                




Mike,


>2.)  Think about the ability of users to run commands outside of the
>command line process - remote commands, 3rd party software command
>lines,etc.  A PC user with the ability to run remote commands won't be
>stopped by the limited access setting.  I won't name names but we have a
>3rd party software that provides their own menu system and command line
>interface - guess what - limited capability is never brought into play.


but object level security still applies for this kind of access, doesn't
it?

I see we will need to look into some of these security utilities.

I understand, without some kind of exit-point programming, you can't stop
this
remote access?

Thanks,

OLiver

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.