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?"
Nobody can read it anyway!
But seriously, if you provide root access to the system, what good is a Perl obfuscator/encryptor/compiler going to do? Nothing can really stop someone with a will and enough free time from decrypting the code.
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.
It occurs to me that asking a bunch of pro-open-source geeks how to best maintain control over closed-source code in an sub-ideal environment is perhaps not the best idea ever. In fact, I would suggest that you double-check any answers you get here, as, for all you know, they're purposefully sub-par solutions designed to lull you into a false sense of security so the code can be more easily nabbed.
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
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!
This sounds like such a BAD setup: security through obscurity (in Perl?!), basic inability to understand root. After all, if hackers can reverse-engineer DVD software to decrypt all movies, your Perl script doesn't stand a chance. And I bet you're putting a password in it!!
:) Modify the script to load once, delete the file, and respond to requests. See perldoc -q 'hide the source'.
But assuming you know what you're talking about, it's an interesting puzzle.
Read-only as root? Mount a write-protected media. CD, floppy, USB dongle. Some hard drives let you set a write-protect jumper. Or you could go with that modified kernal that someone else mentioned here.
Obfuscating Perl? Install a Sony rootkit!
Everyone is entitled to his own opinions, but not his own facts.
[boggle]
You're as bad as all the damn proprietary software vendors who try to prevent people from examining their compiled code in a hex editor or decompiling it.
Why do you want to do this? Is the code proprietary? Does the code contain security sensitive information?
If the latter, then jeez, that's just plain piss poor design. In the case of the former, just put a license warning in the code. It's impossible to "protect" overall design and algorithms anyway.
You can obfuscate the code of course, but really, that's just an exercise in futility.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
> Those dudes had a fairly nasty pack/unpack decryption sequence in their pay webmail system
> that I never got around to cracking.
A student who knows Perl and has a long weekend on his hands can buzz through that sort of thing with ease, or a student with a bit less Perl knowledge could post it on the Perlmonks Obfuscated Code section and claim it's "unbreakable", practically guaranteeing it would be broken within fifteen minutes. (Deobfuscation is a recreational activity for some people, and obfuscated Perl code is incredibly susceptible to it, especially if the obfuscation is automatic, as with the sort of thing you're talking about; in fact, for someone who's reached the point of thinking in Perl, obfuscated Perl code is almost easier to read than normal code in another language (such as C).)
Cut that out, or I will ship you to Norilsk in a box.