OSSEC is a HIDS (Host Intrusion Detection System) and as they are
beginning to developing a web interface (in PHP) because I proposed
the use of Django. I forwarded this post here because has been very
interesting, it's commenting about the security in web frameworks.


---------- Forwarded message ----------
From: Ian Scott Speirs <[EMAIL PROTECTED]>
Date: 10 ago, 14:27
Subject: Proposal for the Web User Interface
To: ossec-list


Jonas wrote:

> On 9 ago, 23:33, Jeff Schroeder <[EMAIL PROTECTED]> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to