Re: Octave restricted mode?

[Jaroslav Hajek]

On Mon, Mar 15, 2010 at 1:39 PM, John W. Eaton <address@hidden> wrote:
> On 15-Mar-2010, Jaroslav Hajek wrote:
>
> | for use of Octave in web applications (which I'm myself interested
> | in), I started to think about allowing Octave to run in a "secure"
> | mode.
> | For instance, it could include the following restrictions:
> |
> | 1. spawning external processes (system, popen, fork, exec etc) is not 
> allowed
> | 2. cd is not allowed
> | 3. mkfifo, symlink, etc are not allowed
> | 4. addpath etc. are not allowed
> | 5. only files in current directory can be fopen()-ed, stat()-ed etc.
> | 6. likewise for other compiled functions where this is possibly needed.
> |
> | I know this won't make Octave hacker-proof, because exploitable bugs
> | (like buffer overruns) are to be expected in Octave, but at least it
> | should make it significantly harder to hack a web application
> | providing access to Octave terminal.
> |
> | thoughts?
>
> Would you disallow all uses of these functions, or just direct uses
> from teh command line, or functions defined by a user in this
> restricted environment (i.e., the functions the user uploads to the
> server that is running the restricted-mode Octave)?  If you disallow
> all uses, then you will break a lot of things.  For example, the help
> system.
>
> I think it makes more sense to leave Octave alone and instead create a
> server environment (chroot jail or similar) that makes it impossible
> for a user to do any damage to the server or anyone elses environment.
>
> jwe
>

OK, I educated myself a little about chroot jails and similar tools. I
agree it's far more powerful. Thanks.


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz