Controlling who can run an executable

**Mike Meyer** · Oct 4 '05, 03:45 AM

Re: Controlling who can run an executable

"Cigar" <chrisgarland67 @hotmail.com> writes:[color=blue]
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her. (Going to the competition
> and using her program.)[/color]

First thing to know; you can't stop someone who's sufficiently
determined to run the program. The best you can do is raise the cost
of breaking your security to be more than any value that could be
gained from doing so.
[color=blue]
> What my client cannot prevent:
> - access to the .exe
>
> What my client is looking to prevent:
> - running of the exe by un-authorized individuals.[/color]

Not quite.
[color=blue]
> Ideas I've had to prevent someone from running the app:
> - ask for a password every time the program is run. (I wonder how
> quickly they will complain about this, not very secure once everyone
> eventually finds out what the password is)[/color]

If only authorized people have the password, then this works. The
problem is that her employees are probably authorized, but she doesn't
trust them to not take the program to her competition. Which brings
up an alternative goal:

Prevent running of the exe on unauthorized hardware.
[color=blue]
> - make a little hardware dongle and check to see if it's on the
> parallel port. (old idea)
> - check for an encrypted flash drive and try to read an encrypted file
> from it. (new idea)
> - buy the client a Microsoft Fingerprint Keyboard and figure out if it
> will make the clients life easier (two minutes of research showed this
> idea has multiple problems)[/color]

Note that these three all use the idea of unauthorized hardware, not
people.

You don't need to install special hardware to get that. There are a
number of pieces of hardware that you can find in a modern computer
that may have a unique serial number you can use as a
dongle. Possibilities include a CPU serial number, an HD serial
number, and the MAC address of any network cards: ethernet, wireless,
and apparently FireWire drivers have them. People have used all of
them in the past.
[color=blue]
> What I want:
> - the simplest thing that could possibly work![/color]

Telling her "Don't let your employees near the computer with media, or
when it's connect to a network." That could possibly work, for some
definition of work. You need to define how difficult you want breaking
your security to be. Then we know what "work" means, and can figure
out what "the simplest thing" is.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

**Paul Rubin** · Oct 4 '05, 04:45 AM

Re: Controlling who can run an executable

"Cigar" <chrisgarland67 @hotmail.com> writes:[color=blue]
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her. (Going to the competition
> and using her program.)[/color]

Exactly what is the threat here? Misuse of confidential data, or just
the code itself? Does the code do anything that fantastic? Did the
employees sign NDA's? Usually this kind of thing is taken care of by
legal agreements. Occasionally there are disputes that make the news
(Microsoft and Kai-Fu Lee, etc.) but they make the news precisely
because they're rare.

What is the competitor going to do with this code even if they get it?
It's just keeping track of transactions and stuff, right? It's being
tailored to one person's specific preferences and requirements, and
the competitor's needs will be different and they may as well just use
something generic.

Your best bet may be to just explain this to the client, that the most
valuable thing in a business is relationships; technical secrets
aren't nearly as big a deal as some people like to think.

Also, is there an office network? Maybe you could run the program on
a server that most employees wouldn't have access to. They'd use it
through some limited client program or through a web browser.

If you really want to do something with a hardware token, I like this
stuff: <http://basiccard.com>. Assuming you're in the USA, buy from
the Canadian distributor since shipping from Germany is very expensive.

**Myles Strous** · Oct 4 '05, 05:55 AM

Re: Controlling who can run an executable

Mike Meyer wrote:
[color=blue]
> You don't need to install special hardware to get that. There are a
> number of pieces of hardware that you can find in a modern computer
> that may have a unique serial number you can use as a
> dongle. Possibilities include a CPU serial number, an HD serial
> number, and the MAC address of any network cards: ethernet, wireless,
> and apparently FireWire drivers have them. People have used all of
> them in the past.[/color]

What's more, Tim Golden's wmi module (see
http://tgolden.sc.sabren.com/python/wmi.html) makes getting at these
numbers very easy:

import wmi
c = wmi.WMI ()
for thingy in c.Win32_Network Adapter():
print "Network Adaptor", thingy.MACAddre ss
for thingy in c.Win32_Process or():
print "Processor" , thingy.Processo rId
for thingy in c.Win32_BIOS():
print "BIOS", thingy.SerialNu mber
for thingy in c.Win32_BaseBoa rd():
print "BaseBoard" , thingy.SerialNu mber
for thingy in c.Win32_SystemE nclosure():
print "System Enclosure", thingy.SerialNu mber
for thingy in c.Win32_DiskDri ve():
print "Disk Drive", thingy.PNPDevic eID
for thingy in c.Win32_Physica lMedia():
print "Physical Media", thingy.SerialNu mber

Regards, Myles.

**Svennglenn** · Oct 4 '05, 06:55 AM

Re: Controlling who can run an executable

> What I want:[color=blue]
> - the simplest thing that could possibly work!
>[/color]

Have the program check for a file hidden somewhere on the computer.
For instance, if the file dummyfile.dll doesn't exist in the
windows/system32 folder the program just doesn't start. And when you
install the program on her computer just add this file. And if anyone
copies the program the can't run it on any other computer because they
doesn't know the name of the file that's needed to start the program.

How about that?

**Cigar** · Oct 4 '05, 10:25 AM

Re: Controlling who can run an executable

Mike Meyer wrote:[color=blue]
> First thing to know; you can't stop someone who's sufficiently
> determined to run the program.[/color]

I have explained to her that I can't prevent someone who REALLY wants
her program from tossing a rock through her front window and making off
with her PC. They'd get the hardware and the executable along with the
client and transactions data. She conceeded that that would be out of
my scope of being able to protect her program.
[color=blue][color=green]
> > Ideas I've had to prevent someone from running the app:
> > - ask for a password every time the program is run. (I wonder how
> > quickly they will complain about this, not very secure once everyone
> > eventually finds out what the password is)[/color]
>
> If only authorized people have the password, then this works. The
> problem is that her employees are probably authorized, but she doesn't
> trust them to not take the program to her competition. Which brings
> up an alternative goal:[/color]

I may have to just put password protection in and if she hangs herself
by 'sharing' the password with underlings she trusts (at the
present)... again that's outside of my control of protecting her.
[color=blue][color=green]
> > What I want:
> > - the simplest thing that could possibly work![/color]
>
> Telling her "Don't let your employees near the computer with media, or
> when it's connect to a network."[/color]

Currently this app is running on a stand alone PC. There was a big
concern about hackers getting at her program or data from over the
internet. I complemented her on this level of security. No floppy
drive either.

**Paul Rubin** · Oct 4 '05, 10:45 AM

Re: Controlling who can run an executable

"Cigar" <chrisgarland67 @hotmail.com> writes:[color=blue]
> I may have to just put password protection in and if she hangs herself
> by 'sharing' the password with underlings she trusts (at the
> present)... again that's outside of my control of protecting her.[/color]

You could have the password automatically change once a month. Give
her a master list of passwords and tell her to lock it away. Each
month she refers to the list and gives underlings a new password.
[color=blue]
> Currently this app is running on a stand alone PC. There was a big
> concern about hackers getting at her program or data from over the
> internet. I complemented her on this level of security. No floppy
> drive either.[/color]

If the app is not being used too often, install it on a laptop and
lock the laptop in a drawer when not in use.

**Cigar** · Oct 4 '05, 10:55 AM

Re: Controlling who can run an executable

Paul Rubin wrote:[color=blue]
> "Cigar" <chrisgarland67 @hotmail.com> writes:[color=green]
> > Now that I'm three months into the development of this program, my
> > client tells me she would like to protect her investment by preventing
> > her employees from doing the same to her. (Going to the competition
> > and using her program.)[/color]
>
> Exactly what is the threat here?[/color]

I think the BIGGEST threat here is a feeling of vulnerablity. She now
realizes that she is in a position that her competition was many years
ago when she came into possesion of program the 'other side' was using
and that she is now vulnerable. She wants to feel safe in the
knowledge that she didn't reach into her pocket and pay thousands of
dollars for a program that now could now be used by her competition.
Nobody wants to pay money to level the playing field for all in a
business environment.
[color=blue]
> Misuse of confidential data, or[/color]

It's just a collection of names, addresses, phone numbers, birthdays
and drivers licences/health cards. I can think of a few dishonest
things that could be done with this but her competition has the
basically the same clients.
[color=blue]
> just the code itself?
> Does the code do anything that fantastic?[/color]

Not by my standards but it is slowly replacing a paper system. (Police
officer shows up and says 'We've just arrested John Smith. Has he sold
you anything in the last 90 days. The client says 'Just a minute' and
reaches for a set of 4" d-ring binders and turns hundreds of pages
looking for a Smith name...) My client is relived that this senario
will soon disappear.
[color=blue]
> Did the employees sign NDA's? Usually this kind of thing is taken care of by
> legal agreements.[/color]

Good question! I'm pretty sure not but that's something I could
suggest to her.
[color=blue]
> What is the competitor going to do with this code even if they get it?[/color]

Simplify their lives. See above.
[color=blue]
> It's just keeping track of transactions and stuff, right?[/color]

You are correct sir.
[color=blue]
> It's being
> tailored to one person's specific preferences and requirements, and
> the competitor's needs will be different and they may as well just use
> something generic.[/color]

Not really. The client just wants to track people and what they buy,
sell or put on buyback. Their competitions needs are the same.
[color=blue]
> Also, is there an office network? Maybe you could run the program on
> a server that most employees wouldn't have access to. They'd use it
> through some limited client program or through a web browser.[/color]

A network exists but the client insists on a standalone PC.

**Paul Rubin** · Oct 4 '05, 11:25 AM

Re: Controlling who can run an executable

"Cigar" <chrisgarland67 @hotmail.com> writes:[color=blue]
> I think the BIGGEST threat here is a feeling of vulnerablity. She now
> realizes that she is in a position that her competition was many years
> ago when she came into possesion of program the 'other side' was using
> and that she is now vulnerable. She wants to feel safe in the
> knowledge that she didn't reach into her pocket and pay thousands of
> dollars for a program that now could now be used by her competition.
> Nobody wants to pay money to level the playing field for all in a
> business environment.[/color]

Suppose that competitor's program that her employee had illicitly
brought her wasn't protected, so she was able to run it. You might
ask her whether, ethical issues aside, she would be willing to use it
on a daily basis, given it sounds like people in her industry know
each other enough that word would probably get back to the competitor,
and any resulting lawsuit would leave her up a creek. If she's not
willing to use her competitor's program under those cirumstances,
should she really be afraid of her competitor using hers? Also, if
all she got from the competitor was an .exe, she'd have no way to
customize it, and vice versa.
[color=blue]
> It's just a collection of names, addresses, phone numbers, birthdays
> and drivers licences/health cards. I can think of a few dishonest
> things that could be done with this but her competition has the
> basically the same clients.[/color]

Well, that sounds pretty confidential to me, but I'll take your word
for it that the competitors are more interested in the code than the
data. I do think she's overestimating the threat.
[color=blue]
> Not by my standards but it is slowly replacing a paper system. (Police
> officer shows up and says 'We've just arrested John Smith. Has he sold
> you anything in the last 90 days. The client says 'Just a minute' and
> reaches for a set of 4" d-ring binders and turns hundreds of pages
> looking for a Smith name...) My client is relived that this senario
> will soon disappear.[/color]

Is there something there that you can't do with a few spreadsheet macros?
[color=blue][color=green]
> > What is the competitor going to do with this code even if they get it?[/color]
> Simplify their lives. See above.[/color]

Lawsuits don't simplify anyone's life ;-).
[color=blue][color=green]
> > Also, is there an office network? Maybe you could run the program on
> > a server that most employees wouldn't have access to. They'd use it
> > through some limited client program or through a web browser.[/color]
>
> A network exists but the client insists on a standalone PC.[/color]

How about two PC's connected by a piece of ethernet cable, but no
outside network connection. The server is a laptop or palmtop locked
in a desk drawer. A little hole is drilled in the back of the drawer
for the power and network cables. The network cable is connected to a
PC on top of the desk that the employees actually use, running a web
browser or the like.

**Michael Ekstrand** · Oct 4 '05, 01:15 PM

Re: Controlling who can run an executable

On Tuesday 04 October 2005 01:43, Svennglenn wrote:[color=blue]
> Have the program check for a file hidden somewhere on the computer.
> For instance, if the file dummyfile.dll doesn't exist in the
> windows/system32 folder the program just doesn't start. And when you
> install the program on her computer just add this file. And if anyone
> copies the program the can't run it on any other computer because
> they doesn't know the name of the file that's needed to start the
> program.
>
> How about that?[/color]

But wouldn't the file name need to be stored in the program somewhere?
as a string which can be discovered using relatively trivial processes?

That makes any protection difficult.

Being totally not a cryptographic expert... the solution I'd see would
be an installer that encrypts the Python package (zip file?) with some
hardware-specific key, and then decrypts it before running it (runner
would need to be in C or something). Or maybe just embeds in itself a
crypographic signature using a hardware key that is verified before the
program can run.

-Michael

**Istvan Albert** · Oct 4 '05, 01:35 PM

Re: Controlling who can run an executable

>was using to track clients and transactions. He couldn't demonstrate[color=blue]
>the program for one reason or another because it was protected in a way
>that neither could circumvent. (She didn't remember how it was
>protected, she had hired this person a long time ago.)[/color]

I'd venture to guess that neither of the people above knew much about
programming. So do the same, create a security measure that protects
against this level of 'threat'.

As others have pointed out the simplest way would be to detect the
presence of a hidden file, or some hardcoded system value, mac address
etc. Obscure this step even more by encrypting some of the information
so that one can't just simply view it in a hex editor.

Istvan.

**Tony Nelson** · Oct 4 '05, 04:15 PM

Re: Controlling who can run an executable

In article <1128395422.904 212.318930@g44g 2000cwa.googleg roups.com>,
"Cigar" <chrisgarland67 @hotmail.com> wrote:
[color=blue]
> I am developing a program for a client. She runs a shop where her
> clients bring in items for sale or short term buyback. Development of
> the program has been going great but she's mentioned that there is a
> 'feature' coming up in the next couple of weeks that she'd like me to
> implement that has me a bit worried.
>
> My client has told me a story of how she hired someone from a competing
> store and that person had brought a copy of the program her competition
> was using to track clients and transactions. He couldn't demonstrate
> the program for one reason or another because it was protected in a way
> that neither could circumvent. (She didn't remember how it was
> protected, she had hired this person a long time ago.)
>
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her. (Going to the competition
> and using her program.)[/color]
...

Call the competition and ask them what they used. Point out that it
worked. If they won't tell you, just look at their software until you
find out.
_______________ _______________ _______________ _______________ ____________
TonyN.:' *firstname*nlsn ews@georgea*las tname*.com
' <http://www.georgeanels on.com/>

**Dennis Lee Bieber** · Oct 4 '05, 05:05 PM

Re: Controlling who can run an executable

On 3 Oct 2005 20:10:22 -0700, "Cigar" <chrisgarland67 @hotmail.com>
declaimed the following in comp.lang.pytho n:
[color=blue]
> I am developing a program for a client. She runs a shop where her
> clients bring in items for sale or short term buyback. Development of[/color]

Sounds a bit like a pawn-shop (or, as the one in town bills itself,
a "loan company"). Given the later (message) comment about the police
showing up, there is a routine possibility of the place being used to
fence stolen goods <G>
[color=blue]
>
> My client has told me a story of how she hired someone from a competing
> store and that person had brought a copy of the program her competition
> was using to track clients and transactions. He couldn't demonstrate
> the program for one reason or another because it was protected in a way
> that neither could circumvent. (She didn't remember how it was
> protected, she had hired this person a long time ago.)
>[/color]
Considering that such information is the type of stuff one would use
a DBMS... is there any chance the reason the program couldn't be
demonstrated is that it couldn't connect to the database server? Having
a client .exe doesn't do much good if the first thing it does is try to
open a database connection. <G>
[color=blue]
> Now that I'm three months into the development of this program, my
> client tells me she would like to protect her investment by preventing
> her employees from doing the same to her. (Going to the competition
> and using her program.)
>[/color]
Lock the server machine into a closet. Store the data in some DBMS,
put the database access logic on the same machine. Run a simple
web-server (CherryPy/CherryTemplate may be enough -- web server and
business logic in one place). FIREWALL the server machine so that ONLY
the web server is available. Have the employees connect to the web
server... Short of breaking physical doors, or a poorly configured
firewall (letting someone remotely mount the server's drives) there is
nothing for an employee to carry away -- not even a "client program"
since it is all web-based (Now, if you are really paranoid, you will
remove printers and external media, so that one can not even take away
screen image captures that only show what the program interface looks
like).
[color=blue]
> What my client cannot prevent:
> - access to the .exe
>[/color]
Well, if all machines on the LAN can get to the web server, no
problem...
[color=blue]
> What my client is looking to prevent:
> - running of the exe by un-authorized individuals.
>[/color]
Do you mean /in the shop/ or rather if someone had obtained the
executable and took it to some other computer? A locked up, firewalled,
server will prevent the physical transport of the executable.

For "in shop" access... Well... Using WinXP with a very short
screen-saver timeout means you give each employee an account/password
just to log into the machine. You could also set up the web server to
require a DBMS log-in (which might be saved in the browser -- FireFox --
since that still required the XP login to get to that browser setting).
That allows a second chance at restriction, as some employees might be
able to login to the external machines but still not have a login to the
DBMS -- unless employess start sharing logins, and there is nothing you
can do about that except discipline the employees when caught.

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]

**Cigar** · Oct 4 '05, 05:35 PM

Re: Controlling who can run an executable

Paul Rubin wrote:[color=blue]
> Suppose that competitor's program that her employee had illicitly
> brought her wasn't protected, so she was able to run it. You might
> ask her whether, ethical issues aside, she would be willing to use it
> on a daily basis, given it sounds like people in her industry know
> each other enough that word would probably get back to the competitor,
> and any resulting lawsuit would leave her up a creek. If she's not
> willing to use her competitor's program under those cirumstances,
> should she really be afraid of her competitor using hers? Also, if
> all she got from the competitor was an .exe, she'd have no way to
> customize it, and vice versa.[/color]

Oh I agree. (I just thought of something while writing a respond to
this) What if she DID get the program running and only told me she
couldn't and came up against the same morale, legal and technical
issues that you're pointing out here and decided against using the
program. I guess maybe part of her doubts that her competition would
look at her program and come to the same m,l,t, conclusions about not
using it if it fell into their hands.

(I'm only guessing at how my client arrived at the decision to protect
her program. All indicators suggests she is a moral, ethical and kind
hearted person)
[color=blue][color=green]
> > It's just a collection of names, addresses, phone numbers, birthdays
> > and drivers licences/health cards. I can think of a few dishonest
> > things that could be done with this but her competition has the
> > basically the same clients.[/color]
>
> Well, that sounds pretty confidential to me, but I'll take your word
> for it that the competitors are more interested in the code than the
> data. I do think she's overestimating the threat.[/color]

Again I agree... but I would like to assuage her concerns as much as I
can technically. It will keep a roof over my head awhile longer.
[color=blue][color=green]
> > Not by my standards but it is slowly replacing a paper system. (Police
> > officer shows up and says 'We've just arrested John Smith. Has he sold
> > you anything in the last 90 days. The client says 'Just a minute' and
> > reaches for a set of 4" d-ring binders and turns hundreds of pages
> > looking for a Smith name...) My client is relived that this senario
> > will soon disappear.[/color]
>
> Is there something there that you can't do with a few spreadsheet macros?[/color]

Are you trying to put me out of a job? :)
[color=blue][color=green][color=darkred]
> > > What is the competitor going to do with this code even if they get it?[/color]
> > Simplify their lives. See above.[/color]
>
> Lawsuits don't simplify anyone's life ;-).[/color]

Costly for all. I do agree.
[color=blue][color=green]
> > A network exists but the client insists on a standalone PC.[/color]
>
> How about two PC's connected by a piece of ethernet cable, but no
> outside network connection. The server is a laptop or palmtop locked
> in a desk drawer. A little hole is drilled in the back of the drawer
> for the power and network cables. The network cable is connected to a
> PC on top of the desk that the employees actually use, running a web
> browser or the like.[/color]

That might fly. I'll have to ask her about that.

**Bengt Richter** · Oct 4 '05, 05:55 PM

Re: Controlling who can run an executable

On 4 Oct 2005 03:49:50 -0700, "Cigar" <chrisgarland67 @hotmail.com> wrote:
[color=blue]
>Paul Rubin wrote:[color=green]
>> "Cigar" <chrisgarland67 @hotmail.com> writes:[color=darkred]
>> > Now that I'm three months into the development of this program, my
>> > client tells me she would like to protect her investment by preventing
>> > her employees from doing the same to her. (Going to the competition
>> > and using her program.)[/color]
>>
>> Exactly what is the threat here?[/color]
>
>I think the BIGGEST threat here is a feeling of vulnerablity. She now
>realizes that she is in a position that her competition was many years
>ago when she came into possesion of program the 'other side' was using
>and that she is now vulnerable. She wants to feel safe in the
>knowledge that she didn't reach into her pocket and pay thousands of
>dollars for a program that now could now be used by her competition.
>Nobody wants to pay money to level the playing field for all in a
>business environment.[/color]
So the biggest threat would seem to be her competition posting requirements
here and having some showoff post a complete solution ;-)

Regards,
Bengt Richter

Controlling who can run an executable

Controlling who can run an executable

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment