|
Re: "safe" perl cron environment?
by iburrell (Chaplain) on Dec 02, 2002 at 17:49 UTC
|
The only way to do this would be to use capabilities to eliminate root's special priviledges. If you are really paranoid, you might want to investigate encrypting the file system with the scripts and only mounting the file system after the capabilities have kicked in.
The main question I have is why are you trying to prevent root from gaining access to the scripts. Are you running on an unprotected machine? Do you not trust your system administrators?
Here are some things to think about: people with root access usually have physical access to the machine. If they want to, they can reboot the machine and run anything, completely bypassing any protection.
| [reply] |
|
|
The main question I have is why are you trying to prevent root from gaining access to the scripts. Are you running on an unprotected machine?
No, I'm trying to protect the machine in the best possible ways.
Do you not trust your system administrators?
I 85% trust my system admin.... It's the 15% I worry about. :-)
Here are some things to think about: people with root access usually have physical access to the machine. If they want to, they can reboot the machine and run anything, completely bypassing any protection.
That's true. And if they did that I'd probably know about it. It's possible, but I'm more worried about a remote root vulnerability. Still, if by using ACLs or encrypted file systems I could make that difficult, it would be worth some effort.
| [reply] |
Re: "safe" perl cron environment?
by Callum (Chaplain) on Dec 02, 2002 at 17:39 UTC
|
If your root account in untrustworthy all bets are off -- don't do anything that matters on any box where you can't trust root. | [reply] |
Re: "safe" perl cron environment?
by demerphq (Chancellor) on Dec 02, 2002 at 18:22 UTC
|
I have to say that there is a delicious sense of irony in your comment
but not nearly as important as the 4 scripts which I consider to be trade secrets. I'd like to use free software as much as possible.
:-)
Afaik ROOT will _always_ be able to access your scripts. I am even hesitant to believe that ACL's will help. Whats to stop the admin setting the computer to run in single user mode as root, then changing the ACL's and then reviewing your code? Even worse, presumably your stuff will be getting backed up, so the sysadmin could take the backup restore to a seperate machine and then change ACL's to her hearts content and you would never even know.
And sysadmin hacks aside there are also things like running your code under -d and trace or even more elaborate hacks to get perl to regurgitate your code (howabout using B::Deparse on the code...)
Ultimately there is NO way in perl (that I am aware of) that will keep your code truely secret. It will always be possible for someone with sufficient privs to access the code.
Sorry,
--- demerphq
my friends call me, usually because I'm late....
| [reply] |
|
|
have to say that there is a delicious sense of irony in your comment
Yes... Sorry about that, but it makes sense in the end... The scripts implement a system which stands to make a ton of money for a non-profit.
I'm really not too concerned about rebooting in single-user mode. I'm more concerned about remote root vulnerabilities.
Ultimately there is NO way in perl (that I am aware of) that will keep your code truely secret. It will always be possible for someone with sufficient privs to access the code.
If this is really true then that is the answer to my question.
John
| [reply] |
|
|
Yes... Sorry about that, but it makes sense in the end...
Heh. No apology needed. Even if it was for a for-profit. :-) Ya gotta do whatchya gotta do!
If this is really true then that is the answer to my question.
(Un)fortunately I believe it is. Although i think it would take a skillful person to do it. But then that holds true of decompiling an executable too.
BING! Heres a _really_ nasty way to do something like what you want: write a C wrapper that embedds perl inside of it. Then put your perl script within the C wrapper (perhaps encrypted using some reliable C library) and then have the wrapper pass the code to the embedded perl instance to be executed. At least that way it becomes nearly impossible for some kind of man in the middle attack, or the other easily implemnted routes from the command line.
Dunno, could be a pipe dream, but i think it would have to be an especially talented and motivitated individual that figured that one out.
--- demerphq
my friends call me, usually because I'm late....
| [reply] |
Re: "safe" perl cron environment?
by djantzen (Priest) on Dec 02, 2002 at 17:59 UTC
|
Trying to restrict what root does on its own machine is a losing battle. Even with access control lists prohibiting people from doing everything from using a paging program on your source code and redirecting its output, to ftp'ing the code somewhere, you're struggling against the reason for an administrator account in the first place -- that it can do whatever it wants.
If you're truly concerned about your clients reading the code for these scripts, you might try downloading them and any required modules at runtime. This also obviates the need to propagate your code to the client machines when you update the codebase. See this thread for discussion of this option: Coderefs in @INC (was: Building a Simple Perl Module Database).
| [reply] |
|
|
The first paragraph above makee plenty of sense. Thinking that you can hide something from root on a Unix machine is folly.
However, paragraph the second makes no sense at all! If some code on the box can download the "secret" scripts, then root can read that code and do the same thing. Or he can just edit the code to print out the "secret" material after it has been downloaded. This is not a secure solution.
BTW, have you considered just making your client sign a non-disclosure agreement concerning the content of your "secret" scripts? Then you can just put the scripts on the box and if they ever use them publicly you can sue their pants off.
-sam
| [reply] |
|
|
If some code on the box can download the "secret" scripts, then root can read that code and do the same thing. Or he can just edit the code to print out the "secret" material after it has been downloaded. This is not a secure solution.
Right, mostly I just moved the problem. A working solution would require some form of authentication procedure. Unfortunately, because root can simply read whatever files are needed on the client machine to provide credentials (i.e., username/password, plain text cookie, private encryption key), or su to the scripts' account, there's always going to be the risk of a spoofed client. In order to make this work I think you'd need a fairly elaborate process.
The NDA is a good idea in any case, although given that these are running as cron jobs means probably they aren't visible to the public. So finding out if the NDA has been breached could be hard.
| [reply]
[d/l] |
|
|
It's not clients I'm worried about -- I'm worried about someone stealing my magic algorithms! :-)
| [reply] |
|
|
And I make a habit of running all of my web browser traffic through a logging proxy so I can debug odd stuff. That protects only against semi-skilled attackers which probably means - not root. I really think the author of the question should look at encrypted scripts (see Filter) and consider all the caveats that entails.
Either that or only work on operating systems where root doesn't actually have root access.
Update: I'm really inexpert in this realm but this sort of thing comes up on bugtraq occasionally. I'm gesturing vaguely in the direction of Mandatory Access Control which is a broad area and really isn't my turf. I never really bothered to keep those lists around since I don't operate in environments where the admins aren't trusted.
__SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
"L!", B::svref_2object(sub{})->OUTSIDE;
| [reply]
[d/l] |
|
|
Either that or only work on operating systems where root doesn't actually have root access.
Ok, I'll bite -- what operating systems don't give root root access?
| [reply] |
|
|
I'm not concerned about clients reading my code. I'm concerned about industiral espionage.
| [reply] |
Re: "safe" perl cron environment?
by traveler (Parson) on Dec 02, 2002 at 18:24 UTC
|
Part of the issue is that linux does not have, by default, mandatory access control facilities. This feature is used, e.g., in HR systems. In those environments root cannot access data in some files. In theory root could remove the disk and read the data on another system. The only way to avoid that is to encrypt the data. You might check this site for more information on encrypting files and file systems in Linux.
If you want to look at just access controls, check out SElinux. There are other linux ACL sites, but those implementations suffer from the shortcomings described above.
FYI, "How do I hide my code from everyone" is probably a FAQ. Try Super Search.
HTH, --traveler | [reply] |
|
|
This is by far the most meaning reply to my question. Thanks, traveler.
| [reply] |
|
|
| [reply] |
|
|
|
|
Re: "safe" perl cron environment?
by BrowserUk (Patriarch) on Dec 02, 2002 at 19:47 UTC
|
You'll have to excuse me if I'm being slow here, but isn't the answer to your conundrum as simple as not giving anyone other than yourself true root access?
Ie. If you need to control the access of administrators and the like, set up root-like accounts but only give them access to those parts of the system that you are comfortable with them having access to and place stuff you need to keep to yourself, where only root can access it.
The usual process is to start with tight controls, and delagate rights as the need becomes apparent and in small steps. It may take a while before you reach a balance between everything needing your personal authorisation and where most regular activities can be performed without it, but that is the nature of the beast.
Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.
| [reply] |
Re: "safe" perl cron environment?
by cLive ;-) (Prior) on Dec 02, 2002 at 19:22 UTC
|
You don't specify what the script does apart from connect to the DB. But if you're really paranoid and it's viable, why not run the script on another machine and connect to the DB remotely?
.02
cLive ;-) | [reply] |
Re: "safe" perl cron environment?
by fglock (Vicar) on Dec 02, 2002 at 19:39 UTC
|
You could encrypt your program with "gpg",
and then run it using
gpg [some-options] | perl
(gpg will ask for a password)
| [reply]
[d/l] |
|
|
Nice idea fglock. Your solution will work great from the command line. The only problem I foresee is that you're going to run into trouble if the Perl prog is ran as a cron job. You still have to figure out a way to give gpg the password without anyone seeing what it is. If the password is in the "driver" script or a config file root can still read it. I was thinking you could get around this by using a config MySQL table to store the password. You could query the table from your driver script. Only problem with that is you still need to connect to the DB in the first place and then you run into the problem of hiding that login & password. Bugger.
--
vek
--
| [reply] |
Re: "safe" perl cron environment?
by converter (Priest) on Dec 02, 2002 at 20:10 UTC
|
ACLs, encrypted filesystems? If you don't trust root, you should reserver uid zero for yourself and delegate controlled access to administrative functions to other users with sudo. sudo is a much more widely-used and supported solution and would bring with it none of the stability or support issues related to ACLs and crypto filesystems.
| [reply] |
My conclusions
by jhanna (Scribe) on Dec 03, 2002 at 22:45 UTC
|
Thanks to all who have posted, I think you've helped me understand better the issues.
As I mentioned, I'm primarily concerned with industrial espionage and someone trying to steal my proprietary algorithms.
There are a couple of scenerios for this:
1) Josephene hacker finds a here-to-fore unannounced / unpatched remote root exploit on my nearly inpenetratable system. Obviously, if there are no processes running as root and no root cron entries, this is much harder. She must resort to capturing a core image and decompiling.
2) Someone physically breaks into our plant and steals the HD out of the server. An encrypted filesystem and some sort of wipe-if-booting-out-of-my-environment boobytrap are the best options here.
3) The inside job (always the most probable):
3a) a rescue image boot -- see #2 above
3b) our sys-admin is payed off to steal the scripts -- Here the best defense is that he doesn't know the root password. That is probably workable in this case.
So the big questions remain where/how to store the key for the encrypted filesystem and how to implement a wipe-if-booting-out-of-my-environment boobytrap. Hmmmm...
john | [reply] |
|
|
The wipe-if-booting option is probably inoperable as if I had stolen your drive, I wouldn't try and boot from it, I'd just view it as a secondary drive from my own system.
As for storing the key(s) to your encrypted filesystem(s), probably the best place would be a microdrive or keyring memory device. You can put these in your pocket (or the safe) when you (or trusted surrogate) leave at night and replace them in a network attached drivebay/reader in the morning.
Of course, this precludes your systems running 24/7.
Alternatively, you could have the keys located on a remote (home?) system and require your systems to fetch the keys from that remote system (via SSL? or similar).
You then have the problem that if one of your systems goes down, you (or your trusted surrogate) is needed to physically restart that system (as it would need your logon to make the connection to the key server).
Then two places have to be physically compromised before you become vulnerable.
Is this more than an academic exercise?
Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.
| [reply] |
|
|
It is more than an academic exercise. I'll need to deploy in about six months. I'm still weighing the alternatives.
The simplest case is just set everything important (including Perl) to root owned, read only mode 500. (Ok, maybe perl can be executed by other), kill all non-essentials and then hope noone finds an exploit. It doesn't help with the stolen disk problem, but it is easy and works fine out of the box.
There's also another solution that came up -- using public key crypto you can do a reatime mixmaster type deal where the key is stored locally and requires decryption from a number of cooperative servers -- the key finally arrives only encoded with a local key and can be decoded and used, but never stored. Temporary session keys protect the individual transmissions. It's clunky, but I believe that if done correctly it requires the hacker to have to hack each participating system to steal the key. It also requires some fancy code signing to make sure the program that implements it has integrety.
That sounds like a fun crypto problem, but I'm not sure I want to spend my time that way.
john
| [reply] |
