LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2004, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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
Comments: To: m n <>
In-Reply-To:  <>
Content-type: text/plain; charset=US-ASCII

m n <> 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 Senior computing specialist mathematical statistician

Back to: Top of message | Previous page | Main SAS-L page