Limiting Command Line Executable

[randyelliott]

Good Day,

I have a MS Access (Access 2000 now upgraded to 2003) database that
tracks customer information. One function of this database is to
create an encrypted license file for our software, which is then
emailed out to the customer. The encryption string is based on
information in the database and can only be generated by executing a
DOS command. This is done from within the database by clicking a
button on a form that triggers a bunch of VBA code that culminates in
running the DOS command -- that command ends up being something like
"C:\Tools\encrypt C:\licenses\customerABCD.txt." This all works fine
and it runs on a Windows XP Pro PC. That it works at all is largely
due to research on this and other newsgroups.

The current problem is that we've now hired an intern that I'm not
completely comfortable with. I want this intern to be able to create
licenses from within the database by clicking the button, but I do not
want him to be able use the encryption routine from the command line.
The reasoning here is that there are certain safeguards (a maximum
valid time, for example) placed on the licenses that can be created in
the database, but if executed from the command line, any license could
be created. Certainly I can take away command line access (by removing
privileges to cmd.exe), but this also breaks the VBA command line
execution. Also of note, the intern will be accessing the PC with the
database using only Remote Desktop (over a VPN) as he will be in a
different office and using the database is the only reason the intern
will be on this machine - I plan to lock down his account as much as
possible.

Any suggestions?

Can I make the database run as System (instead of running as [Intern],
for example)?

Could I could create a new local user with very limited permissions --
no rights to log on, for example -- but who has execute privileges on
the encryption program and have the database (or at least its
encryption function) execute under that username? If I use "Runas"
with the "/savecred" switch in a shortcut, will the saved credentials
be available at other times?

Thanks for your help.

[Tom van Stiphout]

On 10 Jul 2005 17:19:21 -0700, ra**********@earthlink.net wrote:

Handling the most sensitive code a company has, should be left to the
most trusted people in that company. How in the world did you get the
idea of assigning this task to an intern you don't fully trust?

You might be able to eliminate the command line interface and then
further lock down your app, but why trying to finess it, with a chance
your imagination is not as good as the intern's?

The other thing you can do is swing over all the way to the other
side, and assign the task to the most computer-illiterate person in
the company. That strongly reduces the risk that the expanded
priviledges will be used incorrectly.

-Tom.

Good Day,

I have a MS Access (Access 2000 now upgraded to 2003) database that
tracks customer information. One function of this database is to
create an encrypted license file for our software, which is then
emailed out to the customer. The encryption string is based on
information in the database and can only be generated by executing a
DOS command. This is done from within the database by clicking a
button on a form that triggers a bunch of VBA code that culminates in
running the DOS command -- that command ends up being something like
"C:\Tools\encrypt C:\licenses\customerABCD.txt." This all works fine
and it runs on a Windows XP Pro PC. That it works at all is largely
due to research on this and other newsgroups.

The current problem is that we've now hired an intern that I'm not
completely comfortable with. I want this intern to be able to create
licenses from within the database by clicking the button, but I do not
want him to be able use the encryption routine from the command line.
The reasoning here is that there are certain safeguards (a maximum
valid time, for example) placed on the licenses that can be created in
the database, but if executed from the command line, any license could
be created. Certainly I can take away command line access (by removing
privileges to cmd.exe), but this also breaks the VBA command line
execution. Also of note, the intern will be accessing the PC with the
database using only Remote Desktop (over a VPN) as he will be in a
different office and using the database is the only reason the intern
will be on this machine - I plan to lock down his account as much as
possible.

Any suggestions?

Can I make the database run as System (instead of running as [Intern],
for example)?

Could I could create a new local user with very limited permissions --
no rights to log on, for example -- but who has execute privileges on
the encryption program and have the database (or at least its
encryption function) execute under that username? If I use "Runas"
with the "/savecred" switch in a shortcut, will the saved credentials
be available at other times?

Thanks for your help.

[Steven Platt]

Have you tried to remove batfiles in a GPO? Also disable the scripting in
that same setting. Just check if it works. If it doesn't I will see if
there is something else I can think of.

-Steven-
<ra**********@earthlink.net> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Good Day,

I have a MS Access (Access 2000 now upgraded to 2003) database that
tracks customer information. One function of this database is to
create an encrypted license file for our software, which is then
emailed out to the customer. The encryption string is based on
information in the database and can only be generated by executing a
DOS command. This is done from within the database by clicking a
button on a form that triggers a bunch of VBA code that culminates in
running the DOS command -- that command ends up being something like
"C:\Tools\encrypt C:\licenses\customerABCD.txt." This all works fine
and it runs on a Windows XP Pro PC. That it works at all is largely
due to research on this and other newsgroups.

The current problem is that we've now hired an intern that I'm not
completely comfortable with. I want this intern to be able to create
licenses from within the database by clicking the button, but I do not
want him to be able use the encryption routine from the command line.
The reasoning here is that there are certain safeguards (a maximum
valid time, for example) placed on the licenses that can be created in
the database, but if executed from the command line, any license could
be created. Certainly I can take away command line access (by removing
privileges to cmd.exe), but this also breaks the VBA command line
execution. Also of note, the intern will be accessing the PC with the
database using only Remote Desktop (over a VPN) as he will be in a
different office and using the database is the only reason the intern
will be on this machine - I plan to lock down his account as much as
possible.

Any suggestions?

Can I make the database run as System (instead of running as [Intern],
for example)?

Could I could create a new local user with very limited permissions --
no rights to log on, for example -- but who has execute privileges on
the encryption program and have the database (or at least its
encryption function) execute under that username? If I use "Runas"
with the "/savecred" switch in a shortcut, will the saved credentials
be available at other times?

Thanks for your help.

[randyelliott]

Tom,
Thanks for the reply -- reassignment of the task was not my idea and
is a stopgap measure while I port the application to SQL Server with a
web interface. My question is perhaps more appropriately a Windows
security issue and so I've cross-posted there.
--Randy

[Sparda]

"" wrote:

Good Day,

I have a MS Access (Access 2000 now upgraded to 2003)
database that
tracks customer information. One function of this database is
to
create an encrypted license file for our software, which is
then
emailed out to the customer. The encryption string is based
on
information in the database and can only be generated by
executing a
DOS command. This is done from within the database by
clicking a
button on a form that triggers a bunch of VBA code that
culminates in
running the DOS command -- that command ends up being
something like
"C:Toolsencrypt C:licensescustomerABCD.txt." This all
works fine
and it runs on a Windows XP Pro PC. That it works at all is
largely
due to research on this and other newsgroups.

The current problem is that we've now hired an intern that
I'm not
completely comfortable with. I want this intern to be able to
create
licenses from within the database by clicking the button, but
I do not
want him to be able use the encryption routine from the
command line.
The reasoning here is that there are certain safeguards (a
maximum
valid time, for example) placed on the licenses that can be
created in
the database, but if executed from the command line, any
license could
be created. Certainly I can take away command line access (by
removing
privileges to cmd.exe), but this also breaks the VBA command
line
execution. Also of note, the intern will be accessing the PC
with the
database using only Remote Desktop (over a VPN) as he will be
in a
different office and using the database is the only reason the
intern
will be on this machine - I plan to lock down his account as
much as
possible.

Any suggestions?

Can I make the database run as System (instead of running as
[Intern],
for example)?

Could I could create a new local user with very limited
permissions --
no rights to log on, for example -- but who has execute
privileges on
the encryption program and have the database (or at least its
encryption function) execute under that username? If I use
"Runas"
with the "/savecred" switch in a shortcut, will the saved
credentials
be available at other times?

Thanks for your help.

Yes, you are on the right lines there of running the database as a
diffrent user, what i belive you need to do is make another user
acount, which is basicly going to be totaly redundant, it will only be
used for running the database, but the problem is, even with the runas
command, you carnt just enter the users password in the command line
like you can with good OS’s, no your prompted for it, whcih makes
automated startup of diffrent programs difficult, the best way i can
see is if you write a small visual basic program, that utilises the
shell command, so it would be some thing like (for example)
shell("runas /user:luke calc") this would atempt to start windows
calculator as user luke, unfortunatly you canot enter the password for
the user on the command line, so some how you are going to have to
pass the users password to the newly open shell console (command
prompt) so that the password is entered automaticly.

--
Posted using the http://www.windowsforumz.com interface, at author's request
Articles individually checked for conformance to usenet standards
Topic URL: http://www.windowsforumz.com/Customi...ict555396.html
Visit Topic URL to contact author (reg. req'd). Report abuse: http://www.windowsforumz.com/eform.php?p=1765523

[Sparda]

"Sparda" wrote:

Yes, you are on the right lines there of running the database
as a diffrent user, what i belive you need to do is make
another user acount, which is basicly going to be totaly
redundant, it will only be used for running the database, but
the problem is, even with the runas command, you carnt just
enter the users password in the command line like you can with
good OS's, no your prompted for it, whcih makes automated
startup of diffrent programs difficult, the best way i can see
is if you write a small visual basic program, that utilises
the shell command, so it would be some thing like (for
example) shell("runas /user:luke calc") this would atempt to
start windows calculator as user luke, unfortunatly you canot
enter the password for the user on the command line, so some
how you are going to have to pass the users password to the
newly open shell console (command prompt) so that the password
is entered automaticly.

of course after you have got the program runnign as a diffrent user,
you then have to sort out the ntfs permisons so that that user can
read and write to the nessasery files, but your intern canot.