[Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...)

[Paul L. Allen]

Andreas Ericsson writes: 

> Regexes is sugarcoating for text mangling. Useful indeed, but not strictly 
> necessary.

You can write everything in assembler if you want to.  Lots more lines of
code so it takes a lot longer to write and there are likely to be
proportionately more bugs.  You can write C to do text matching, but it's
a lot easier if you have a regex library.  Or if you use perl. 

> Unions and structs are a part of ANSI. It's perfectly acceptable to have 
> an array of structs containing arrays of structs with arrays of arrays (or 
> whatever) in them, allowing for infinite depth arrays.

Gosh, you have unions and structs.  Ah well, that's everything you'll ever
need. 

> Hashes are convenient, but not necessary since it's perfectly possible
> for you to hop the pointer yourself.

Hashes are not just convenient, they solve many problems that would scale
badly and run very slowly without them.  Of course, you can write your own
hash code, but good hashing code is difficult to write.  Or you could find
a C library.  Or you could use perl. 

> Bah. Some plugins should be written in C. Those that parse a lot of text 
> should be written in perl, and those that rely on external commands for 
> their data retrieval (like snmpget and fping) should be written in unix 
> shell (it handles program execution better than perl, since it can fork() 
> instead of execve()).

And if you rely on external commands that generate a lot of text that you
have to parse? 

>> So what I'm saying is that for most cases you don't need C.  Take a
>> look at the perl plugins. NONE of them make use of C-code modules that
>> I know of.
> 
> The Socket module works with C-code underneath, as does SNMP and File.

The socket module is part of the standard distribution.  Perl is written
in C.  Neither of those facts mean that it is sensible to rewrite perl
plugins in C just because perl is written in C. 

>> Most competent programmers understand that programmers generate the
>> same average number of *fully* debugged lines of code a day no matter
>> which language they write in.  It is left as an exercise for the reader
>> to compute the average code-density ratio of perl and C. 
>> 
>>> Those same functions can be called and linked from any C program without 
>>> the intermittent layer and the top-level code.

With many more lines of code needed to do so, especially if you need
text mangling.  I made the point about productivity and your response
ignored it. 

>> You can do anything from any language, if you try hard enough. 
>> 
> My point exactly. Why try 'hard enough' to write it in perl if it needs C 
> under the hood any way?

Why work hard to code something in many lines of C that could be done in
a few lines of perl?  BTW, code generated in C is just a bunch of
opcodes and data.  Why write it in C when it's just opcodes under the
hood?  Why not write raw machine instructions? 

> On a serious note though; Do you know how many bugs and potential bugs me 
> and the other Owl developers have fixed in perl 5.8.3? Last time I checked 
> we were at patch-level 23 (each patch fixes 3 or more bugs). Patches have 
> been submitted, but it's a serious load of code so I'm thinking it'll be a 
> while until they're allowed in the tree.

You're doing a good job with the patches.  But, as you admit, you've
submitted patches for other things like Apache.  You may have the luxury
of not running Apache until you've done a thorough audit and fixed all
the holes, most people don't.  The same thing goes for perl. 

> Also, we value security above functionality, which isn't always
> functional enough for the kind of ad-hockery many perl programmers
> (read script kiddies) indulge in.

Yeah, script kiddies like the programmers for the Swedish state pension
scheme.  After the main project code went way off schedule, some of these
"script kiddies" knocked up some code in perl as an interim system.  It
worked so well that the main project code was dropped and the interim
perl code upgraded to have all the functionality in the spec.  The perl
code took a small fraction of the time to write that had already been
spent on the main code. 

>> A plugin is a gigantic thing to audit if you check everything it calls.
> 
> Ofcourse. Hence the kernel, glibc and gcc audit, but that's a one-time 
> penalty.

The penalty can be amortized over everything you run, but it's a large
penalty.  And it's a moving target unless you intend to stick to that
version forever. 

> Auditing a perl plugin makes the one-time penalty even worse, since it 
> requires auditing of perl itself as well (not to mention the modules it 
> uses).

That's a fair point.  But given the choice between a plugin that does
what I need written in perl or no plugin at all, I take the former. 

>> I remember mentioning to you just how much of the TCP stack is in kernel
>> space these days but I haven't seen a response.
> 
> What do you want me to respond to? You weren't asking me anything if I 
> remember things correctly, merely stating that it was (which is true, so I 
> don't have a respond for that).

The point is that most of the stack runs in kernel space and is therefore
a potential vulnerability.  Yet another thing to audit. 

> Besides, perl is as vulnerable as anything to kernel bugs.

And C isn't?  Hint: perl is written in C.  So if you can write something
in perl that's vulnerable to a kernel bug you can write the same thing in
C with the same vulnerability. 

>> A *good* coder works around the limitations of many platforms rather
>> than coding purely for his own platform.  Perl simplifies that process
>> by already knowing about many of those problems. 
>> 
> You put too much faith in Larry Wall et al.

The same faith I put into linux and apache.  I know that they are going
to contain bugs but they are better than the alternatives.  I know that
open source development means they are likely to improve.  I know that
they may contain bugs, but in the end I need an OS and webserver. 

> Also, a false sense of security is worse than real sense of insecurity.

I don't trust any software to be secure.  Short of disconnecting servers
from the internet, there isn't much I can do to be confident I am
totally secure.  Unlike you, I don't believe that your patches will
make any of these things totally secure because I don't fool myself that
I can think of every possible vulnerability or that totally new exploit
mechanisms will never be found. 

>> In practise, the only plugin I have seen that needs to run
>> an external command as another user called sudo.
> 
> Which means a legitimate sudo call will exist on the stack (free fire 
> zone).

Are you advocating setuid as a safer alternative? 

> Yes, but at what cost? Do we need to mark certain scripts as unsafe for 
> the EPN, and how do we go about doing that? Config variables in nagior, or 
> with shell-scripts wrapped around them?

How about separate directories? 

-- 
Paul Allen
Softflare Support