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

[Dave Lowe <seclistinbox@xxxxxxxxx>]

Hi Guys

Just a quick introduction. My name is Dave Lowe and I am writing the
new web user interface (wui) for ossec.

It is coming along nicely and is written in PHP, built upon Daniel
Cids original wui.

I will investigate Django and other python web frameworks when time
permits and will consider using one in a future version of the wui.

This version will be PHP.

If you need to contact myself off list, my email is: dlowe at ossec
dot net


Dave


On Aug 11, 7:23 am, Jonas <jonas....@xxxxxxxxxxxxxx> wrote:
> 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/a7b5...
>
> 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