Eric wrote:
> I'm no expert on tainting, but a quick look through Inline.pm shows
> me that while this is enough to untaint reading the config file, it
> won't be enough for making directories or writing files. That means
> that only previously cached inlined code (in previously created .Inline
> directories) will work under taint. New or modified inlined code will
> throw an "insecure dependency" error.
>
> Also, I'd rather have untainting be an option that I have to set
> explicitly, just to keep me mindful of what's happening.
>
> use Inline ( C =>
> Config =>
> UNTAINT => 1,
> ...
> );
I've been asking around on this taint thingy. Here is my current plan:
1) I'll add an UNTAINT config option (thanks Eric) to defeat any taint
checking so Inline can run in with -T.
2) A SAFEMODE config option to actually perform extra security checks
when running with UNTAINT.
3) As far as the 'config' file is concerned, I'll leave the format
as-is, but I'll eval it in a Safe.pm sandbox, if SAFEMODE is set.
4) To keep the syntax shiny clean I'll add new Inline shortcuts so that
use Inline UnTaint, Safe;
use Inline Bash;
is the same as:
use Inline Bash => DATA =>
UNTAINT => 1 =>
SAFEMODE => 1;
which is the same as:
use Inline Config =>
UNTAINT => 1 =>
SAFEMODE => 1;
use Inline Bash => 'DATA';
TMTOWDTI, ya know. But beware, 'cause this won't work:
use Inline Bash => Config =>
UNTAINT => 1 =>
SAFEMODE => 1;
use Inline Bash => 'DATA';
This syntax implies that the config options are Bash specific, but
they're not. They're generic ones (like DIRECTORY) so Inline::Bash will
(should) croak.
Brian
New, safer .signature :)
--
perl -MInline=untaint,safe -Tle 'use Inline C=>q{SV*JAxH(char*x)
{return newSVpvf("Just Another %s Hacker",x);}};print JAxH+Perl'
