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

[Jonas <jonas.esp@xxxxxxxxxxxxxx>]

Ian Scott, I forwarded your post to the Django-users group. You can
read an answer here:

http://groups.google.com/group/django-users/browse_thread/thread/a7b5d66d04340d53/

On 10 ago, 14:27, Ian Scott Speirs <spei...@xxxxxxxxx> wrote:
>
> 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