Slashdot Mirror
'Protecting' Perl Code?
An anonymous reader asks: "Ok, so here is the scenario: my company has some software that is used internally and it is written in Perl. We now need to put this code on a server that has 'public' access (it's a university machine). We provide root access to the system for the purpose of learning, but we need to keep the code from being viewed or edited. Is there anything to do besides the 'perl2exe' and the ActiveState compiler? How effective are those really at protecting code?"
You could scambling the code un-readable uncompiled.
One of my professors told me a story about how he once worked with a guy that mantained a project. To help keep his job he would always submit the code scrambled with all names of variables and functions seemingly meaningless. He showed him this one day and asked, "How can you read this?" He said, "I can't. I write the code, put the source through a filter program and then submit the result. If they need someone to fix it or read it or improve it, they will have to go through me." This was back in the early 80's.
..and it's called "Perl". You don't need to do anything at all for your code to be unreadable.
If it's for learning and people have root, why put it on this server if you don't want people to learn from it?? Still want to do it? Move this perl code to another box and call it via RPC.
My second though was permissions. Why do the students need root access? Couldn't you make some new account that had permissions to do anything but access that one directory?
My last thought is a sandbox (or I think the BSD concept of a Jail is the same idea). If you were to run Linux on Linux (Xen, or just some other sandbox, maybe even chroot) then you could give them root, while keeping them out of the true root.
It's a tough situation. Does it really have to be on that server? You can't stick it on a new server your company buys for the purpose and donates (what is more important, My last idea (a bit extreme, I would think) would be to modify the Perl interpreter to run the perl code through a decryption algorithm first (so the source on disk would be encrypted so it couldn't be read). With open source software, there is no reason this isn't possible (would hurt performance though).
Does Perl support some kind of tolkenizing? When you run a Python script you get the .pyo (I think) file that is basically the cached compiled Python byte code. Can you do that with Perl? It isn't perfect (can be disassembled back into Perl, but without variable names, etc) but it is better than plain text.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
"Or he could try a Perl obfuscator"
People have written perl obfuscators? Why? I've never seen perl code that needed an obfuscator.
This is such a frequently asked question that there's even a faq in the documentation that is distributed in almost every single perl distribution.
perldoc -q 'hide the source'
If that's not simple enough, then see the thread on perlmonks.org about it.
If you still think that obfuscating the source code is going to gain your company anything, then I doubt anyone really wants to see your code at all. (You don't happen to work for Blackboard, do you?)
http://www.donarmstrong.com
If you are giving root access to the machine to students, you do not need to put your preciousss perl application on the same machine. In fact, you need to NOT put it there, because even if you obfuscate it, encrypt it, or compile it, it's possible to reverse the process. Obfuscated code can be analyzed and understood, plus it's going to take some real talent and time if you want to do it right, so it's expensive. Encrypted code needs to be decrypted before it can be executed. Compiled code can be decompiled.
You might use something like a BSD Jail or some other kind of server virtualization, so it merely looks like your software is on another machine. If it is really important that this program remains your dirty little secret, don't put it on a machine which you don't control. Really.
But if you really want to put it on the same machine, try compiling it into a binary, and not draw any attention to it, to avoid people getting curious about it. Still, if someone finds it and takes enough of an interest in it, all bets are off.
I suffer from attention surplus disorder.
It sounds like you're a bit confused, if the people are supposed to have access to learn, then why are you denying them access to learn from this script. It sounds like you really just shouldn't have this script on there, as was said before, you should move it elsewhere and call it remotely.
But MOST IMPORTANTLY, I wouldn't put anything of value or importance onto a machine where uni students have root access. If you remote call, whose to say they won't break the call, if you obfuscate, whose to say that they won't just break the script or delete or replace it. It just seems silly...
Perhaps you should give them access to a root-like group, then not put this file in that group. I think you problem is that you want more complex permissions then you've relegated yourself to having.
http://monkeyserver.com --- weeeeee
Why don't you install yourself a nice Kernel with grsecurity.
Using it's permissions system, you can allow root to login and do whatever you'd like, you but can set grsec so that only certain other groups/systems are able to view/run etc your perl code.
The permissions system is very configurable and it's a steep learning curve with not a real lot of documentation. But playing with it for a few days should get you all figured out.
Using grsec it's possible to allow root to login and really do zero damage, it's a great system. I don't think any Linux box should be allowed on the 'net without this patch! There are other systems (SeLinux) that offer the same sort of thing, so if GrSec isn't quite what you need be sure to look at the others.
Using a system like this means all those "they have root forget about it" isn't true anymore, you can configure it so root can do very little damage to the working system, but still have access to edit all those files the normal pleb user accounts can't.
Tim
The problem with Perl is that it's an interpreted language. That is, you need an interpreter to read the code and then run it. And if the perl binary can read the code, then so can you.
An obfuscator could work, but then someone could easily nuke the program, or just generally mess with it.
Honestly, I think it's a retarded idea to begin with. First, drop ALL the root access, no excuses. Add stuff back in with Sudo as needed, giving each command careful review. Then, rewrite your app to work with suidperl, and run that with setuid root, or with sudo.
That's the technical answer. But honestly, why are you afraid of them looking at your code?
Don't thank God, thank a doctor!
Perl is already Tolkienized -- just look at the start of every source file!
More seriously, you can save the internal representation, but it's easy for someone skilled to turn that back in to mostly-readable source code. You don't even lose the variable names; Perl keeps them around. (For globals, you have to -- you always have to do a symbol lookup. Lexicals don't have symbolic access; the compiler turns these into indexes into pads attached to the internal representations of code objects. However, these lexical pads do keep the variable names around as they're important for error messages, among other things.)
(Guess who just wrote about lexical pads in a Perl book not more than ten minutes ago?)
how to invest, a novice's guide
[boggle]