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

[Andreas Ericsson]

Paul L. Allen wrote:
>>> Perl has a lot of stuff that C lacks without adding libraries that 
>>> are not a standard part of C.
>>
>> But not without perl modules.
> 
> Really?  Regexes are a standard part of the perl language, no modules
> required.  If you want regexes in C you have to hunt out non-standard
> (as in not supplied with C compilers and not part of the ANSI standard)
> libraries.  The same goes for many perl features.
> 

Regexes is sugarcoating for text mangling. Useful indeed, but not 
strictly necessary. If you want sockets and some other basic necessities 
you need modules.

> C has fairly primitive data structures, but if you grab non-standard
> libraries or write your own code you can have the equivalent of perl's
> arrays and hashes.  Etc.
> 
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. Hashes are 
convenient, but not necessary since it's perfectly possible for you to 
hop the pointer yourself.

>>> Stuff that allows perl programmers to be more
>>> productive and means they don't have to take care to avoid buffer
>>> overflows.
>>
>> There's always a tradeoff in development time if execution time is 
>> more important. This is true in perl as well.
> 
> Yes, it is.  I wouldn't write an operating system in perl, 

Correction, noone *could* write an OS in pure perl. In fact, noone can 
even write an OS in pure C.

> and I wouldn't write a plugin in C. 

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

>> So what you're saying is;
>> Code it in C, then write some more code so that the third layer of 
>> code you write (the perl script) can access the code you wrote first.
> 
> 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.

>> How does this make development time faster and more efficient?
> 
> 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.
> 
> 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?

>>>> If we set all that aside there is still the issue of having every 
>>>> bug ever intoduced in Perl spread to every plugin written in it
>>>
>>> As opposed to every bug ever introduced into the C compiler and 
>>> libraries,
>>
>> ... which ALSO fan down into Perl.
> 
> ROFL.  I wondered if you'd fall for that one.  I didn't think you were
> that foolish, but you were. Do you know how much of the perl installation
> process is devoted to detecting known bugs in operating systems and
> compilers and finding the secure alternatives?  Perl tries hard to avoid
> hitting on known bugs in OSs and compilers.  Perl also does not use every
> feature in C that a C programmer might use.
> 
No. I've been writing programs since I was eight but I have never 
installed perl (doh!).
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. 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.

>>> along with every bug introduced by plugin authors being careless with
>>> buffer overflows and who use printf without a format specification.
>>
>> A plugin is not a big thing to audit. Fix the bugs and you're back in 
>> the fast lane again.
> 
> 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.
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).

> 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).
Besides, perl is as vulnerable as anything to kernel bugs.

> However, as Karl pointed out, the important issue is that plugins get
> written.  More people are happy writing them in perl than in C. 
> If you were to put your money where your mouth is and convert all the
> perl plugins to C then I think they would be accepted. 

I do that for plugins we use which run terribly slow in perl. I'll post 
them on our website as soon as I get green light from the boss 
(copyright stuff).

Right now I'm working on nrpe, and creating an acceptable nrpe-client 
for vms systems. This work is derived from code already under the GPL 
license, so no copyright issues apply.

> 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. Also, a false sense of 
security is worse than real sense of insecurity.

>> I know that, but how does it work under the hood? If perl (the 
>> program) is invoked every time a precompiled image needs to execute I 
>> seriously doubt the effectiveness of the epn. If it doesn't, then how 
>> can it the elevated privileges of the script be retained?

> Now that's a good question, and one I don't have the answer to since
> I haven't looked at epn (too unstable for my liking).  Embedded perls
> are usually C programs that call the perl functions needed. 

If it works as I think would seem logical (for it to be a real speedup); 
The perl EPN calls perl once to compile the script and then caches the 
executable image. When it's time to run it, it vfork()'s and execve()'s 
and points the instruction pointer to the executable image and things 
run as expected.
If the above is wrong, then please correct me. If it's not, the 
following questions arise.

Is this accomplished using trampoline calls or some voodoo I'm not aware 
of? How does kernel patches preventing an executable stack affect this?
Is the EPN capable of sharing perl functions (truly amazing if it is)? 
If not, how much memory does each script consume at a bare minimum? Will 
problems arise if we're running lots of different checks, and how can we 
prevent nagios from bringing the system to kneel from memory exhaustion?

> I don't
> see any reason, in principle, why setuid scripts could not be handled
> by epn, but it would probably get messy with separate instances being
> forked, and piped communications, and might require some rewriting of the
> plugin. 

If it works as guessed above, there's no way setuid plugins can be handled.

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

Some input from the EPN author would be much appreciated here. 
Preferrably in low-level teach-speak, so we get all the details.

> I expect that is possible to conceive of problems that cannot be
> handled that way.  But they can all be worked around. 

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? Will the EPN be able to 
detect when programs as opposed to perl builtins are being called, and 
how much code (most likely non-trivial such) would that lead to?

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