in reply to "safe" perl cron environment?

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).

Replies are listed 'Best First'.
Re: Re: "safe" perl cron environment?
by samtregar (Abbot) on Dec 02, 2002 at 18:15 UTC
    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]
Re^2: "safe" perl cron environment?
by diotalevi (Canon) on Dec 02, 2002 at 18:13 UTC

    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;

    [download]
[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]
Re: Re: "safe" perl cron environment?
by jhanna (Scribe) on Dec 02, 2002 at 18:42 UTC
    I'm not concerned about clients reading my code. I'm concerned about industiral espionage.
[reply]

In Section Seekers of Perl Wisdom