[
Lists Home |
Date Index |
Thread Index
]
sorry, but i disagree - strongly.
that's what ibm said 20 years ago and every design since has had to cope
with 640k base memory ranges and other "that'll be more than enough"
decisions.
compare with codd's approach which was to build security as a
fundamental of the relational database model from day 1, but not limits
like those mentioned below.
dbms limits to record size, index components, number of keys, etc have
plagued many applications and it would be a shame to build these things
into a standard.
what if you mandate a limit, but technology or a smart programmer works
out how to cope with more - do we get xml 2.1-<memory
limit>2**32</memory limit> as a spec?
i'm not saying they're not issues, just that they're not good issues for
specifications
rick
On Fri, 2003-10-03 at 01:25, Bullard, Claude L (Len) wrote:
> I agree with all of that. I will also adjust my terminology.
> Old habits like old code change only with concerted effort. :-)
>
> The points made about the XML specification needing changes
> are quite useful. Hopefully, the Core XML WG is paying
> attention. We've gotten away with it but we know it has
> to change. What would you say is the best way to get
> started on that? One might be to get Roger Costello
> to add a section to his best practices page. It doesn't
> fix the code but it will increase awareness.
>
> len
>
>
> From: David Megginson [mailto:dmeggin@attglobal.net]
>
> Bullard, Claude L (Len) writes:
>
> > Any system can be hacked and security bugs show up in all of them.
> > The issue of the monoculture is real enough, but not a catastrophe.
> > One could make the claim that securing one system is all that is
> > needed, but the facts say otherwise.
>
> As John mentioned, you need to be careful about using the word
> "hacked", because it has different meanings for different people.
> For many developers, "easily hacked" means "easily extended and
> maintained". If you use the term "cracked" in your postings, there's
> no ambiguity.
>
> Microsoft is going through a painful, decade-long transition from
> standalone and single-user to networked and multi-user -- the
> transition means abandoning many principles that were originally dear
> to them (and brought them great success in the standalone days), like
> *always* favouring convenience over security. Some of the
> optimizations they made, like putting so much in the kernel (including
> a lot of GUI code), will also keep coming back and biting them for a
> while, since every bit of code inside the kernel is a potential
> vulnerability.
>
> Posix operating systems also have vulnerabilities, of course, but
> because they were designed to be multiuser and networked from the
> start, their fundamental design is more sound: as I mentioned earlier,
> Posix systems tend to have relatively thin kernels and do most of
> their work in user space, so they can be hardened to a large extent
> simply by making sure that the user-space programs do not have root
> permissions. Not everyone does that, but at least it *can* be done.
>
> So, what about XML and its related specifications? I'm afraid that
> we're more like Microsoft than like the Posix systems: we're starting
> with glaring security holes like external DTD subsets and external
> entity references for the sake of convenience, and we will have to fix
> those holes later if XML ever becomes popular on the Web. With no
> fixed limit on element names, number of attributes, nesting depth,
> etc., XML applications can also easily fall prey to buffer-overflow
> attacks or denial-of-service attacks if they are not very carefully
> written. I believe that the old SGML declarations were very annoying,
> but it might not hurt to set some arbitrary, very high limits for the
> next version of XML, such as
>
> Maximum name length: 4096 characters
> Maximum attributes: 1024
> Maximum element nesting depth: 65536
>
> etc. Every robust XML application has to do that anyway to avoid
> either buffer-overlow or DOS attacks (by memory exhaustion), so it
> would be a good idea to start spreading a good, standard practice now.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
