Date: Mon, 20 Dec 2004 15:20:54 -0800
Reply-To: cassell.david@EPAMAIL.EPA.GOV
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "David L. Cassell" <cassell.david@EPAMAIL.EPA.GOV>
Subject: Re: setuid and code protection
In-Reply-To: <20041217175251.57571.qmail@web52808.mail.yahoo.com>
Content-type: text/plain; charset=US-ASCII
m n <iced_phoenix_news@yahoo.com> wrote:
> <Disclaimer>
> This is unix specific..apologies to other crowds.
> </Disclaimer>
No apologies necessary. OS-specific topics are allowed. Hey,
if they let statisticians like me in, they'll let anyone in!
> There have been many threads in the past regarding
> code protection (via macro/data step compilation,
> encryption, etc etc), and invariably, someone always
> posts a method to break the solution.
>
> Has anyone had any success with a scheme such as:
> 1.) Store code to be protected in a common directory
> structure, with permissions 700.
> 2.) Write a setuid C (for example) program that sets
> the effective user id to the owner of the program
> directory (NOT root), and invokes a batch sas program
> that calls the desired macros.
>
> I'm interested in the possible security hazards of
> such a scheme (specific to SAS--I recognize there are
> plenty of generalized setuid concerns), because it
> seems like a good approach if security can be
> controlled (the burden of read protection is then on
> the OS).
I'm not a setuid/setgid specialist, but this doesn't sound like
a safe approach to me. As a rule, the bigger the program, the
more potential problems running it under setuid (even if you're not
running it setuid root). The GTK+ programmers specifically
recommend against something like this, and they don't have
anywhere near the lines of code that SAS does.
The problem that I see is not in your own code, but in the fact that
you will be calling up thousands of lines of compiled code which
have their own little.. umm.. peccadillos. What happens when your
client is running your code and interrupts the processing, either
with a keystroke (control-C anyone?) or with some accidental combination
of data/actions/etc. ? Will things be at risk as soon as those SAS
windows pop up and the client gets to start fiddling a bit?
As you know, just putting files in a protected directory is not
enough to keep people out. Particularly people who can get root
privileges using anything from su and sudo on down. This approach
doesn't seem as secure as some of the approaches that have already
been suggested in SAS-L (which you have already looked over).
> <Aside>
> I recognize that some SAS-Lers believe that open code
> is the best policy, but there are some instances in
> which code protection is certainly necessary (my case:
> an I/T Services firm providing data analysis for a
> large auto corp...there are many other bidders for our
> work, and the large auto corp could easily drop our
> firm from the contract if our code was available to
> them).
> </Aside>
I see your concerns. But I think that your stated problem is
really more of a *legal* problem than a programming problem.
In your shoes, I would have a lawyer help me write my own legal
notices about the use and misuse of my code, then help the auto
corp get it set up and running. If the company chooses to do
something like what you fear, then you have grounds for one major
lawsuit. Not only will you (and your lawyer) be rubbing your
hands together saying "..and by this time tomorrow we'll shopping
for a vacation home in Majorca!" (sorry, my son is re-reading
Harry Potter 1 right now) but you'll be a *famous* programmer too.
:-)
HTH,
David
--
David Cassell, CSC
Cassell.David@epa.gov
Senior computing specialist
mathematical statistician
