[ossec-list] Re: Proposal for the Web User Interface

[Ian Scott Speirs <speirss@xxxxxxxxx>]

Jonas wrote:
>
> On 9 ago, 23:33, Jeff Schroeder <jeffschr...@xxxxxxxxx> wrote:
>   
>> In opensource, proposing something is often equivalent to volunteering
>> to do it yourself :)
>>     
> True :)
>
>   
>> Also, php is easier to set up than python / django on a majority of
>> operating systems / distributions
>> simply because it has more market penetration.
>>     
> I disagree totally. Python is being installed by default in the major
> distributions and a Django application can be easily installed via
> Setuptools
Hi all--

I normally don't insert myself into a lot of these discussions nor do I 
like to veer too far off topic or get into anything based on a lot of 
subjective reason (and lastly to reduce the chance of getting spam); 
however, since this involves a) a piece of software I am using (and will 
consider using if I oversee a substantial production environment again) 
and b) security, I'm going to throw a few tidbits from a friend and me.

I forwarded the email to him about this and am putting some of his 
comments here.

/There has been a LOT of Python development.  The benefit (and 
detriment) of Python v PHP is not its immaturity (shared by a LOT of 
library PHP code) but the fact of it's nature of being compiled to 
bytecode before use.  In that realm, it's questionably better than C++ 
-- can be completely obfuscated, with only an API "visible".  Again, 
that's a benefit to the developer doing non-FOSS development, but a 
detriment to the user who wants to code-audit.
/
He and I have been watching the use of and evaluation of open source by 
US government. There are efforts to certify some open source operating 
systems and software and thus provide a huge boost to this are of the 
the software market. His point about code-audits and obfustication are 
relevant from that aspect--they are going to want a guarantee if it's 
used by DOD or DHS.

/As such, it's a trade-off.  You can get good or bad library code with
either, and IIRC there's a mod_python so that python doesn't have to
run CGI.  Certainly there COULD be advantages at run time, to prior
compile in terms of speed and resources taken, which for most projects
today is quite offset by the need to compile BEFORE testing, AFAIK.

//Looking at this being "ossec" -- Django is built on one primary 
principle:
| DRY (Don't Repeat Yourself) Principle states:
|
| Every piece of knowledge must have a single, unambiguous, 
authoritative | representation within a system.

  From a security standpoint, such aims are a NIGHTMARE.  The "same
  piece of knowledge" may have different access needs (hence be
  subdivided in different contexts) or worse, different "taint".
  While that theory DOES help prevent inconsistencies (one value
  updated, another not, for supposedly the same meaning), it tears
  out the whole usage-and-origin framework upon which safe data
  usage is controlled.   To me this is a big red flag.  They
  do mitigate this (maybe) with:
| DRY refers to your source code, not your running program.
    Is that talking about running instances, or data within each?

  Think of a "tied perl hash" (one that resides in a .db hash,
  transparently brought into a %hash, once tied).  That reduces
  instances of information storage for the content of that hash
  by transparently fetching and updating values -- even adding
  when a new key value is assigned.  Presumably, when the program
  exits normally, the "cache" in the %hash variable, and the disk
  copy are in sync.   And when it doesn't exit normally?
  This isn't unique to Python ;)
/
To me as a security professional, the most important aspect of a piece 
of software is a high level of risk mitigation. If using Django or any 
other type of framework increases the risk, I am less likely to adopt 
that. Without a doubt, the greatest value of open source security 
software is its transparency.

/  I'm going to guess that this Django is similar to that PHP template
  system that makes maintenance of "things not covered" such a pain.
/
I can't speak to or of Django because I am not that familiar with it nor 
use it. However, I have been examining a variety of PHP web applications 
recently and have found serious maintenance issues with several of them 
built on common frameworks. I understand that PHPnuke has had some 
serious vulnerabilities discovered in it and I believe the Smarty-based 
software has a few problems too. Granted, being open source allows many 
people to see these and respond to them but the real issue is the design 
and development process undertaken. If a development group is in too 
much of a hurry to get something out so others can see it and become 
potential participants, what does that say about the basic design?

And again I can't speak to that in Django

Just a few thoughts and my .02.

Scott