Fwd: Proposal for the Web User Interface of the OSSEC HIDS
Jonas
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 <spei...@speirs.us>
Date: 10 ago, 14:27
Subject: Proposal for the Web User Interface
To: ossec-list
Jonas wrote:
> On 9 ago, 23:33, Jeff Schroeder <jeffschr...@gmail.com> 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
RajeshD
>
> ---------- Forwarded message ----------
> From: Ian Scott Speirs <spei...@speirs.us>
> Date: 10 ago, 14:27
> Subject: Proposal for the Web User Interface
> To: ossec-list
>
> Jonas wrote:
>
> > On 9 ago, 23:33, Jeff Schroeder <jeffschr...@gmail.com> 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
How about this quote on Python:
"Python is fast enough for our site and allows us to produce
maintainable features in record times, with a minimum of developers,"
said Cuong Do, Software Architect, YouTube.com.
> /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.
What does code audit have to do with compiled binaries or bytecode?
You audit Python source code just as you would audit PHP or any other
code.
I don't understand the comment about Python's immaturity either --
it's been around for over 15 years and it seems to be mature enough
for You Tube, Google, and NASA :)
>
> /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.
If performance is a concern, there are a large number of Python/Django
sites that are performing incredibly well. Django supports memcached
and is able to scale with pretty much any hardware you throw at it.
Python code gets byte compiled on first access. So, there's no
recompilation penalty on every web request. And in any case, it's the
network I/O that takes up a majority of a request's life cycle.
>
> / 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.
> /
That guess is plain wrong! Django is modular enough that you can use
your own layers if you don't like what's in the box. For example, you
can use a different templating system, a different ORM (to an extent),
pretty much any Web Server, a number of different caching backends.
For example, it has well defined interfaces to DB backends, caching
backends, and such so that you can write your own implementations if
your DB or cache is not supported. It lets you use all the agility and
elegance of Python.
> 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.
Most such issues are a result of bad programming decisions more than
anything else. Through DRY, Django actually encourages good decisions.
Django also provides excellent documentation in that respect. But you
can write bad unmaintanable code in any language :) So, this is
neither a PHP problem nor a Python one.
> 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?
Django is actually the perfect framework for situations where you want
to get things out in a hurry. There are numerous stories of people
knocking out serious, stable, high performing code in a weekend that
would take a lot longer with anything else.
>
> And again I can't speak to that in Django
Well, Scott needs to take a more serious look at Django then. He has
too many preconceived notions about bad frameworks. There's no reason
to apply those to Django.