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

[Andreas Ericsson]

Paul L. Allen wrote:
>> 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.
>
For functionality, yes.

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

If the code is written properly, scaling is not a problem. If it isn't, 
no language in the world will do the trick for you.

> 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.
> 
Enter simple mathematics. I argue that good hashing code is trivial to 
write as long as it has been properly implemented from the beginning.

>> 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?
> 
man grep
man sed
man awk
man cut

>>> 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.
> 
SNMP is not, but I guess you missed that. Also, if I read Karl's 
comments on the perl framework correctly, it has almost grown out of its 
own usefulness.

>>> 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.
> 
By reducing the intermittent code layers production times will drop. In 
what way did I ignore the productivity issues?

>>> 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?
> 
Now you're just being silly.

>> 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.
> 
Are you expecting a reply to this?

>> 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.
> 
many != all
Are you making this up, btw? I live and work in sweden but I've never 
seen this pension scheme, or any news or anything about it.

>> 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.
> 
Already discussed and agreed upon.

>>> 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.
> 
Do you think I mainly spent my time working on IDE-drivers while 
auditing the kernel?

>> 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.
> 
'as vulnerable as anything' wasn't there for rhetorical reasons.

>>> 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.
> 
And I'll be happy to provide both. Actually, it's more than just likely 
that some of the code you rely on was written by me, or based off of 
work I put into it. Fun, eh?

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

I don't believe they will make me totally secure. I believe they will 
make me more secure than I would have been without them.

> 
>>> 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?
> 
No, I suggest the script calling sudo shouldn't be cached. If it is then 
evey instance of nagios will have an easy shot at a vulnerability in its 
stack.

>> 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?

Should work out ok. Then we'd only have to add one new variable to the 
main configuration file. 'perl_safe_cache_dir' or something. Code could 
be kept rather clean (well, not any messier than it is at least) and 
consistent, and everybody would be happy.

-- 
Mvh
Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se