This is very good Thad. Thanks for the post.
Gary Polvinale
Denton ATD
garyp@...
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, June 14, 2001 10:03 PM
To: 'vantage@yahoogroups.com'
Subject: [Vantage] Security Questions Resolved
The Following is an e-mail conversation I had with Steve Graham at Epicor
about security.
I believe the text of his responses would be beneficial to any vantage
administrator concerned with eliminating any back doors to the DB.
Keep in mind that this conversation pertains specifically to Vantage 3,
although most of it probably applies to the other versions as well.
Steves response, combined with the following white paper:
http://eranet.epicor.com/ansbook/vantage/public/5/54/546/546mps.htm
has put our mind to rest as far as the security questions go.
Hope this helps someone,
Thaddeus
-----Original Message-----
From: Steve Graham [mailto:scgraham@...]
Sent: Thursday, May 31, 2001 11:55 AM
To: 'Thad Jacobs'
Subject: RE: Unanswered Security Questions
Thad,
1) The Progress Procedure Editor is only called within Vantage by the
Vantage Basic EDITPROG command. This was introduced in version 4.0.
EDITPROG would allow a user to run uncompiled 4GL from within Vantage Basic.
Vantage menu security would allow you to limit access to Vantage Basic. NT
securitry could be used to prevent access to _edit.r. If a VB user in the
future wanted to used the Procedure Editor feature, you would have to allow
him NT access to _edit.r.
_edit.r is the default program used by the Progress client ProWin32.exe. As
long as you provide Prowin32.exe will a -p <initial program> it doesn't call
_edit.r. Vantage uses -p mainmenu.w as its initial program.
2)It could be run by starting Prown32.exe with all the correct parameters
required to connect to the Progress database. However, the .r would have to
be put in a directory path that the Progress client would search thru.
Progress searches the PROPATH, in the Progress.ini file or Vantage.ini file
(4.0) to find .r files. Use NT security to limited WRITE access to these
files to prevent users from modifying them. Our Technical Support web page
has a white paper on suggested permissions to secure the Vantage\Progress
folders.
3) If Progress DB Admin is used to add a user to the db security list, then
Progress is triggered to prompt for a valid userid/password each time a
client connection is made to the database. To avoid having users login
twice, once to Progress, once to Vantage, a -U and -P parameter and value
can be added to the connection string that Vantage uses to start a session.
4) I'm sending the Vantage Security document for your review if you haven't
already recieved it.
DLC\BIN\ProRb32.exe is the actual Report Builder tool interface.
DLC\BIN\ProRE32.exe is the Report Builder engine interface. This is what
Vantage calls when a RB report is run from within Vantage. Using NT
security to control access to these executables would restrict which users
can run them.
-Steve
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, May 31, 2001 10:17 AM
To: 'Steve Graham'
Subject: RE: Unanswered Security Questions
Thank you very much, Steve. This is exactly what I was looking for. We
don't have the payroll module, but we do bill employee hours, at a given
rate to a job. Just a few more questions, and it looks like it looks like
we will be able to begin implementing Report Builder on our end-user
workstations.
1) I'm assuming we can change the permissions on _edit.r, and not affect our
end user Vantage and Report Builder logins. Is that correct?
2) Is there any way a user could run an already compiled progress
application without having access to menu security in Vantage?
3) Can permissions on the master database file be changed for only SYSTEM
and Administrator access without affecting Vantage logins?
It seems that if the DB connection is through TCP, then the user is not
accessing the database file itself, but telling ProControl what to pull from
it.
4)What would be really nice is a list of the following
- Progress files that the user needs write access to in order to run Vantage
/ ReportBuilder.
- Progress files that the user needs read access to in order to run Vantage
/ ReportBuilder.
- Progress files that the user can be locked out of, and still run Vantage /
ReportBuilder.
(assuming these permissions are being controled by NT, and SYSTEM and
ADMINISTRATOR accounts have full rights on those files)
I understand such a [wish] list may take some time to compile, but having
the first three questions answered should be able to get us rolling
immediately.
Thank you very much for your help.
Best Regards,
Thaddeus Jacobs
Assistant LAN Technologist / Vantage Support
Kinematic Automation, Inc
mailto:tjacobs@...
-----Original Message-----
From: Steve Graham [mailto:scgraham@...]
Sent: Wednesday, May 30, 2001 5:49 PM
To: 'tjacobs@...'
Subject: FW: Unanswered Security Questions
Thad,
Sorry to be slow in my response, my email is actually scraham@....
To answer your questions:
1) The only other Progress clint executable that could potentially allow
users to gain acess to the Progress datbase would be, \DLC\Bin\_edit.r.
This is the Progress Procedure Editor, which if your users knew the Progress
4GL programming language, could allow them to write queries to the database.
Even so, all the payroll tables have encrypted codes that only allow Payroll
Managers to see them and they have to log in thru the Vantage menu interface
to get to the data.
2) My suggestion would be to move the database files (located in
\Vantage\DB) to a folder location outside the \DWC shared folder. The
Vantage client accessing the database via a TCP service. The client does not
have to see the database via the mapped drive to the shared DWC folder.
Moving the database files to a folder outside the shared only requires that
you change the path to the database stored in ProControl, allowing the
database service that the clients use to connect to the db, to start. If
the client doesn't know exactly where the database resides it makes it
harder for them to know how to connect to it.
3) The Progress Database Administration tool allows individual tables to be
secured by user. Once implemented a -U and -P user and password parameter
and value would need to be added to the client connection for the client to
connect seamlessly to the database. The Progress manuals and eDocumentation
cover the Admin Tool. If you don't have the manuals you can read the 9.1B
online documentation (8.3A DB Admin didn't change much from 9.1B) by going
to the Progress documentation web site.
http://www.progress.com:/v9/documentation/start.htm#dbcoll
Implementing table security is difficult due to the tight integration
between the Vantage modules. You might be able to secure the most sensitive
table EmpBasic that contains the employee pay rate. Test using a copy of
your production database first.
Hope that helps,
Steve
-----Original Message-----
From: Simon Graham
Sent: Wednesday, May 30, 2001 3:12 AM
To: Steve Graham
Subject: FW: Unanswered Security Questions
Yours I think....
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: 29 May 2001 21:18
To: 'sgraham@...'
Subject: Unanswered Security Questions
Steve,
First of all, I would like to express thanks to Dave and Foster for their
courteous and professional help in regards to securing down Report Builder.
I believe we have the security risk reduced down to a much more reasonable
level than before. By locking down the report editor, we can greatly reduce
the possibility of someone opening the Bin Box Label report, saving it under
a different name, and replacing the part master table with the employee
labor and pay rate fields.
However, there are still some security questions I have posed both by phone
and e-mail, that have been left unanswered, maybe because they are more
related to the Progress background end of things, rather than the actual
Vantage front-end.
In order for any of our users to print reports, they must have the Progress
database client installed on their system. From what I have seen on my end,
THERE IS NO PASSWORD IN THE CONNECTION BETWEEN THE PROGRESS CLIENT, AND THE
PROGRESS DATABASE ITSELF, by default.
This essentially tells management that the progress client should only be
installed on the workstations of those users which have security clearance
to access all of the data contained in the database. Unfortunately, that
clearance is granted to only two people besides the owners, and we have the
necessity of running reportbuilder on numerous other workstations in our
different departments.
We are aware of the option of installing ODBC, and that it presents even
greater security risks. From what I have seen, the only truly secure option
utilizing ODBC is to go with the web-based Crystal Report model, which we
don't want to do unless is is absolutely necessary. Creating and
configuring a web server specifically for the purpose of creating a secure
reporting environment sounds a little cumbersome. It would also require
recreating our Report Builder Reports in Crystal.
We do realize that by limiting Progress client installations to those whom
we don't believe would have the knowledge necessary to exploit such a
security hole, and to only those whom we "Trust", we are reducing the
security risk to a small amount. However, before I tell management that
that is the approach we must take, I would like to have a few questions
answered.
1. Are there any components of the Progress 8.3A Client Install, besides
Report Builder, that present a security risk? How are these locked down?
2. How do we need to set up our file permissions in Windows NT to minimize
the possibility of any tampering with the database files?
3. What would it take to secure individual tables in the Progress Database?
We will only consider this as a last resort, but would like to know how it's
done.
We would like to have these questions answered as soon as possible, as we
have created many Report Builder reports for various departments that could
greatly enhance our productivity. This security issue is the only thing
keeping us from putting these reports into use.
Best Regards,
Thaddeus Jacobs
Assistant LAN Technologist / Vantage Support
Kinematic Automation, Inc
mailto:tjacobs@...
To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please go to:
http://groups.yahoo.com/group/vantage/files/. Note: You must have already
linked your email address to a yahoo id to enable access.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Gary Polvinale
Denton ATD
garyp@...
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, June 14, 2001 10:03 PM
To: 'vantage@yahoogroups.com'
Subject: [Vantage] Security Questions Resolved
The Following is an e-mail conversation I had with Steve Graham at Epicor
about security.
I believe the text of his responses would be beneficial to any vantage
administrator concerned with eliminating any back doors to the DB.
Keep in mind that this conversation pertains specifically to Vantage 3,
although most of it probably applies to the other versions as well.
Steves response, combined with the following white paper:
http://eranet.epicor.com/ansbook/vantage/public/5/54/546/546mps.htm
has put our mind to rest as far as the security questions go.
Hope this helps someone,
Thaddeus
-----Original Message-----
From: Steve Graham [mailto:scgraham@...]
Sent: Thursday, May 31, 2001 11:55 AM
To: 'Thad Jacobs'
Subject: RE: Unanswered Security Questions
Thad,
1) The Progress Procedure Editor is only called within Vantage by the
Vantage Basic EDITPROG command. This was introduced in version 4.0.
EDITPROG would allow a user to run uncompiled 4GL from within Vantage Basic.
Vantage menu security would allow you to limit access to Vantage Basic. NT
securitry could be used to prevent access to _edit.r. If a VB user in the
future wanted to used the Procedure Editor feature, you would have to allow
him NT access to _edit.r.
_edit.r is the default program used by the Progress client ProWin32.exe. As
long as you provide Prowin32.exe will a -p <initial program> it doesn't call
_edit.r. Vantage uses -p mainmenu.w as its initial program.
2)It could be run by starting Prown32.exe with all the correct parameters
required to connect to the Progress database. However, the .r would have to
be put in a directory path that the Progress client would search thru.
Progress searches the PROPATH, in the Progress.ini file or Vantage.ini file
(4.0) to find .r files. Use NT security to limited WRITE access to these
files to prevent users from modifying them. Our Technical Support web page
has a white paper on suggested permissions to secure the Vantage\Progress
folders.
3) If Progress DB Admin is used to add a user to the db security list, then
Progress is triggered to prompt for a valid userid/password each time a
client connection is made to the database. To avoid having users login
twice, once to Progress, once to Vantage, a -U and -P parameter and value
can be added to the connection string that Vantage uses to start a session.
4) I'm sending the Vantage Security document for your review if you haven't
already recieved it.
DLC\BIN\ProRb32.exe is the actual Report Builder tool interface.
DLC\BIN\ProRE32.exe is the Report Builder engine interface. This is what
Vantage calls when a RB report is run from within Vantage. Using NT
security to control access to these executables would restrict which users
can run them.
-Steve
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, May 31, 2001 10:17 AM
To: 'Steve Graham'
Subject: RE: Unanswered Security Questions
Thank you very much, Steve. This is exactly what I was looking for. We
don't have the payroll module, but we do bill employee hours, at a given
rate to a job. Just a few more questions, and it looks like it looks like
we will be able to begin implementing Report Builder on our end-user
workstations.
1) I'm assuming we can change the permissions on _edit.r, and not affect our
end user Vantage and Report Builder logins. Is that correct?
2) Is there any way a user could run an already compiled progress
application without having access to menu security in Vantage?
3) Can permissions on the master database file be changed for only SYSTEM
and Administrator access without affecting Vantage logins?
It seems that if the DB connection is through TCP, then the user is not
accessing the database file itself, but telling ProControl what to pull from
it.
4)What would be really nice is a list of the following
- Progress files that the user needs write access to in order to run Vantage
/ ReportBuilder.
- Progress files that the user needs read access to in order to run Vantage
/ ReportBuilder.
- Progress files that the user can be locked out of, and still run Vantage /
ReportBuilder.
(assuming these permissions are being controled by NT, and SYSTEM and
ADMINISTRATOR accounts have full rights on those files)
I understand such a [wish] list may take some time to compile, but having
the first three questions answered should be able to get us rolling
immediately.
Thank you very much for your help.
Best Regards,
Thaddeus Jacobs
Assistant LAN Technologist / Vantage Support
Kinematic Automation, Inc
mailto:tjacobs@...
-----Original Message-----
From: Steve Graham [mailto:scgraham@...]
Sent: Wednesday, May 30, 2001 5:49 PM
To: 'tjacobs@...'
Subject: FW: Unanswered Security Questions
Thad,
Sorry to be slow in my response, my email is actually scraham@....
To answer your questions:
1) The only other Progress clint executable that could potentially allow
users to gain acess to the Progress datbase would be, \DLC\Bin\_edit.r.
This is the Progress Procedure Editor, which if your users knew the Progress
4GL programming language, could allow them to write queries to the database.
Even so, all the payroll tables have encrypted codes that only allow Payroll
Managers to see them and they have to log in thru the Vantage menu interface
to get to the data.
2) My suggestion would be to move the database files (located in
\Vantage\DB) to a folder location outside the \DWC shared folder. The
Vantage client accessing the database via a TCP service. The client does not
have to see the database via the mapped drive to the shared DWC folder.
Moving the database files to a folder outside the shared only requires that
you change the path to the database stored in ProControl, allowing the
database service that the clients use to connect to the db, to start. If
the client doesn't know exactly where the database resides it makes it
harder for them to know how to connect to it.
3) The Progress Database Administration tool allows individual tables to be
secured by user. Once implemented a -U and -P user and password parameter
and value would need to be added to the client connection for the client to
connect seamlessly to the database. The Progress manuals and eDocumentation
cover the Admin Tool. If you don't have the manuals you can read the 9.1B
online documentation (8.3A DB Admin didn't change much from 9.1B) by going
to the Progress documentation web site.
http://www.progress.com:/v9/documentation/start.htm#dbcoll
Implementing table security is difficult due to the tight integration
between the Vantage modules. You might be able to secure the most sensitive
table EmpBasic that contains the employee pay rate. Test using a copy of
your production database first.
Hope that helps,
Steve
-----Original Message-----
From: Simon Graham
Sent: Wednesday, May 30, 2001 3:12 AM
To: Steve Graham
Subject: FW: Unanswered Security Questions
Yours I think....
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: 29 May 2001 21:18
To: 'sgraham@...'
Subject: Unanswered Security Questions
Steve,
First of all, I would like to express thanks to Dave and Foster for their
courteous and professional help in regards to securing down Report Builder.
I believe we have the security risk reduced down to a much more reasonable
level than before. By locking down the report editor, we can greatly reduce
the possibility of someone opening the Bin Box Label report, saving it under
a different name, and replacing the part master table with the employee
labor and pay rate fields.
However, there are still some security questions I have posed both by phone
and e-mail, that have been left unanswered, maybe because they are more
related to the Progress background end of things, rather than the actual
Vantage front-end.
In order for any of our users to print reports, they must have the Progress
database client installed on their system. From what I have seen on my end,
THERE IS NO PASSWORD IN THE CONNECTION BETWEEN THE PROGRESS CLIENT, AND THE
PROGRESS DATABASE ITSELF, by default.
This essentially tells management that the progress client should only be
installed on the workstations of those users which have security clearance
to access all of the data contained in the database. Unfortunately, that
clearance is granted to only two people besides the owners, and we have the
necessity of running reportbuilder on numerous other workstations in our
different departments.
We are aware of the option of installing ODBC, and that it presents even
greater security risks. From what I have seen, the only truly secure option
utilizing ODBC is to go with the web-based Crystal Report model, which we
don't want to do unless is is absolutely necessary. Creating and
configuring a web server specifically for the purpose of creating a secure
reporting environment sounds a little cumbersome. It would also require
recreating our Report Builder Reports in Crystal.
We do realize that by limiting Progress client installations to those whom
we don't believe would have the knowledge necessary to exploit such a
security hole, and to only those whom we "Trust", we are reducing the
security risk to a small amount. However, before I tell management that
that is the approach we must take, I would like to have a few questions
answered.
1. Are there any components of the Progress 8.3A Client Install, besides
Report Builder, that present a security risk? How are these locked down?
2. How do we need to set up our file permissions in Windows NT to minimize
the possibility of any tampering with the database files?
3. What would it take to secure individual tables in the Progress Database?
We will only consider this as a last resort, but would like to know how it's
done.
We would like to have these questions answered as soon as possible, as we
have created many Report Builder reports for various departments that could
greatly enhance our productivity. This security issue is the only thing
keeping us from putting these reports into use.
Best Regards,
Thaddeus Jacobs
Assistant LAN Technologist / Vantage Support
Kinematic Automation, Inc
mailto:tjacobs@...
To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please go to:
http://groups.yahoo.com/group/vantage/files/. Note: You must have already
linked your email address to a yahoo id to enable access.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/