- Attribute Value
- This link type points to the schema used to define the content of an "atom:content" element of an "atom:entry" document. The "for" attribute is used to identify the QName of the direct child of the "atom:content" element that the link is intended for.
Multiple links with the same "for" value SHOULD have different "type" values; processors are allowed to choose the schema language they best support.
This link can appear in an "atom:feed" document where it specifies the default for all feed elements. It can also appear within an "atom:entry" element. Links in an entry override any links in a feed that have the same "type" and "for" values.
- Expected display characteristics
- Generally, this link is not intended for display, although the "type" attribute would control the display characteristics. This link is intended for automated use.
- Security considerations
- As with any other link.
Security, Middleware, Appliances
RSalz 2700011QK0 668 Visits
A new Atom Link Relation is requested. UPDATE: fixed error so that it refers to content within an "atom:content" element of an "atom:entry" document.
RSalz 2700011QK0 1,038 Visits
The title of this post is a little obscure; it's the subject of an email discussion thread from the cryptography mailing list moderated by Perry Metzger.
The discussion started with posting about a certificate that has a couple-hundred names to it. Somewhere along the thread, Jon Callas posted a brilliant send-up, comparing PKI to the classic (as in, what you learned in high school English) definitions of tragedy, comedy, and farce. I could even follow many of his references. Adam Shostack posted a copy with Jon's permission. It might take a certain combination of computer geek and liberal arts education to get it, but it's worth it.
RSalz 2700011QK0 3,203 Visits
The OpenSSL package is an open source SSL/TLS implementation in C. It includes a pretty comprehensive cryptographic library and, if you're so inclined (or forced to use it) a reasonable ASN.1/DER toolkit. I'm making available my small set of web pages and Perl script that implement a self-service PKI built around OpenSSL. The Perl script and config are under 250 lines and the couple of web pages involved are under 200 lines; there's also a couple of screen shots to guide someone through installing a cert on Microsoft Windows. It's all in the public domain. Enjoy.
UPDATE, a few hours after posting: Added a lockfile to avoid race condition in the script. Unlikely to happen, but possible. Thanks to Peter Sylvester for pointing that out.
RSalz 2700011QK0 563 Visits
This is really funny. If I open a browser window at work and type www.playboy.com I get redirected to an internal web page; the URL tells you all you need to know:
The funny part is that if I replace "boy" with "girl" it works.
I'm too scared to try other ones. ... at least not until my DHCP lease exires.[Read More]
RSalz 2700011QK0 638 Visits
Two weeks ago I said we'd have some IETF Internet-Drafts related to Atom and APP. The first one just got published: draft-rsalz-atom-adv-sec, "Advanced Security Processing for Atom and APP Documents." Whew, what's a mouthful. Most people will find the reading to be tough going, I think. It requires understanding the Atom and APP specs, as well as WS-Security (and by reference, XML Digital Signature and Encryption) . It's probably not a large community of potential readers; Atom/APP is firmly planted in the REST world, and WS-Security, obviously, comes from the Web Services world.
Basically, we use WS-Security so that you can use signatures and encryption over parts of Atom/APP documents, and that you can target those parts to individual or several users. For example, a consulting service could have an Atom feed of their reports, and encrypt those entries that are only available to premium-class customers.
We also define a new element, "atomsec:credentials", that lets an atom:link element hold certificates that can be used to verify any signatures on the pointed-to content, or the SSL certificate for the server. For example, a virtual-hosted APP server could have a different SSL cert for each feed, and the credentials element lets the administrator configure the service document appropriately.
Our goal is to have this be part of the son-of-atompub working group. For now, any discussion should happen on the atompub mailing list.
RSalz 2700011QK0 1,361 Visits
This is pretty cool:
We are very happy to announce that the [IBM Internal] Scrum Community has worked through the logistics required to make drafts of the chapters for A Practical Guide to Distributed Scrum available externally. This is the first time that IBM Press and IBM Legal have taken an agile approach to development of a book. We're excited to be a part of this!
A great deal of IBM software development is distributed. Just within the small DP development organization, we have engineers in three continents and six timezones-and that doesn't count IBMer's in other products that we need to collaborate with. I think IBM has some real experience in distributed scrum, and this book could be very useful to the global agile development community. Please visit the website, read the drafts, and help us make it better.[Read More]
RSalz 2700011QK0 696 Visits
The agile development methodology--er, the agile programming method--er, using "agile"--has a lot going for it. In many ways, it reminds me of the lean and hungry software startup times, when you knew you could close the next sale if you just added that one feature. The flexibility and transparency it provides into the development cycle is great. We just reviewed our progress and made some plan changes that will get reviewed by senior management months before we GA. That is infinitely better than getting surprised one month before you ship.
The one thing I don't like is that design seems to be missing from the process. Or mostly missing. We certainly don't have anything like the classic "waterfall" design documents and process, and I'm not sure that's always a good thing. It seems to me that there's a real high risk of doing a whole bunch of little tactical things that just don't fit together well. And there's nobody with the whole 'big picture' view of things.
I have a personal stake in this, because one of the things that I am particularly good at is seeing the big picture, which components can be re-used and planned for the future, and so on. Agile seems so focused on the now, that there's no room for the next.[Read More]
RSalz 2700011QK0 1,393 Visits
As far as I know, I made this up.
Q: How do IBM'ers first introduce themselves?
A: Hi, who joined?
Those who don't get it might want to look at this video (which is much funnier than my joke): http://www.youtube.com/watch?v=zbJAJEtNUX0
RSalz 2700011QK0 431 Visits
I've been writing about how various aspects of appliances contribute to the overall security of the product. I was talking about "real," physical appliances, but most of what I wrote also applies to virtual appliances -- a product running as a guest image under a hypervisor -- as well. For example, the issues of having no "extra parts" to be attacked is still important, and an important benefit.
But a virtual appliance has other specialized security concerns that physical appliances do not: the hypervisor. While hypervisors isolate systems from each other, and allow greater utilization of the underlying system, Quis custodiet ipsos custodes? (Who will guard the guards?) Put another way, a virtual appliance can be no more secure than the hypervisor on which it is running.
For example, when first creating an instance, the host container will provide a UUID to uniquely identify that instance. We can use the UUID to generate an encryption key, and use that key to encrypt the virtual disk. If the hypervisor is compromised, however, a third-party can be told the UUID and get complete access to the virtual disk. The security assurance that the data is protected, and that the instance will not be moved, cloned, and run elsewhere, is gone.
Is this a concern? I don't know. An internet search for "hypervisor attacks" turns up thousands of hits, including this one from last year that talked about some hypervisor security tooling developed by IBM and NC State.
RSalz 2700011QK0 380 Visits
Two previous posts talked about the security benefits an appliance gets from the physical configuration, and by leaving stuff out. This one is simpler, and talks about the security benefits of knowing what's "on the box."
When an appliance leaves the factory, one of the last steps of the manufacturing process it to install the right firmware on it. The word firmware is a better term than software because it typically includes data, low-level chip controllers and device drivers, and so on. In addition to the technical reasons, it's also a more properly-evocative term of what's installed: a special-purpose monolithic image, as opposed to software running on some server.
The firmware can include a decryption key, and a certificate. When an administrator downloads and installs an update, the existing firmware will check the signature and decrypt the image. (Not necessarily in that order.) The fact that the firmware is encrypted allows the vendor to put it in a reasonably-public web site such as a download support site. Verifying the signature, and using the certificate to verify the signer's credentials, allows the existing firmware to "know" that the new install is authentic (comes from the same source), and unmodified.
Those simple mechanisms allow us to maintain a chain of trust -- we always know exactly what is installed, and are sure of its provenance.
The firmware can also include a signed manifest, that enumerates every file on the appliance, and its digest value. This allows verification of the running image and supporting files, against accidental damage. It is not a full-strength protection against someone installing a corrupt operating system in an adversary's hardware, but the form-factor should prevent that. This shows how multiple security features interact to provide stronger security.
RSalz 2700011QK0 415 Visits
IT appliances can bring a lot to the table in terms of security -- more so that general servers, and especially more so than clouds. A major reason for this is their form factor, the physical configuration of the product. Appliances also benefit because they are not used for general-purpose computing; they're built, sold, and used for a specific set of tasks. (Or to use the IBM term, I guess I should call it workload.)
First, an appliance can be a sealed box with a tamper-indicating switch. If the case is opened, we can refuse to boot. In some circumstances we must just log an audit or diagnostic message. Making the appliance not boot is not a decision to take lightly -- it means that there are really no customer-serviceable parts inside. But if you can do that, you can also add extra features like special non-standard screws, and tamper-evident tape that breaks the seal if the case is opened.
An appliance generally needs some kind of storage to hold the firmware and configuration data. Even if someone opens the box, you went that storage to be somewhat protected. On most motherboards, there is EPROM space for the vendor to use, and you can put some key material there. Make that key be per-device -- this requires some coordination, if not outright ownership, of your manufacturing and fulfillment process. If someone rips the lid off and steals the drive, it will take some time to brute-force the key, and even then only that one, intruded, no-longer-booting, appliance will be compromised.
On some platforms, a TPM (Trusted Platform Module) may be available. This is a small piece of hardware that can verify a digest of various parts of your system -- the boot block, the BIOS, and so on -- and only release a blob (typically a key) if all the parts verify. TPM can be used for DRM (digital-rights management), such as ensuring that only an "authorized" player will display the DVD you bought; I dislike that. But when used in an appliance, to ensure that only the authentic software is running on the product, a TPM can make a lot of sense.
RSalz 2700011QK0 423 Visits
Part of the appeal of appliances is that you know what's running on the hardware. You can't do this on a modern general-purpose operating system. I can go to my Linux workstation and type "ps" and there are things running that are completely mystifying to me. Does my desktop machine really need automated power management? Similarly, I can open my laptop and fire of the task manager, and be completely lost the minute I move from the applications to the processes tab. All I know how to do is click on the CPU column, and if my browser is making the system sluggish, I'll kill it.
On an appliance, I can do a ps -- if such a command existed, which it shouldn't -- and understand and explain everything. Further, I can walk through the filesystem and describe the justification for the existence of every single file. And if I can't do it, the appliance development team certainly can.
When an appliance leaves the factory, it should have only what's needed to perform its task. The supporting infrastructure of a general-purpose computer should be removed as much as possible. Or rather, start with the kernel and add items as you find you need them. The /etc/passwd file, and in fact almost all of /etc? Remove it. The /bin directory? Why? A shell? Your appliance should include some kind of command line, and be complete for problem determination, so get rid of bash, sh, ash, etc. Busybox? Only as a way to package many utilities in a small unit. If needed.
The less stuff you have, the smaller your attack surface: the fewer places folks can sneak in and get you. The fewer moving parts in the appliance, the more reliable it will be. Within reason, of course. If the problem-determination tools are completely integrated into the data-processing capabilities, then you'll get lots of "box becomes completely not responsive, and I can't log in" complaints. And you can take my word on that. :)
RSalz 2700011QK0 848 Visits
From the Symposium on Processing XML Efficiently, our abstract:
This presentation will discuss some of the hardware and software trade-offs in the IBM DataPower XML processor, known as the XG4. The XG4 is a PCI card that parses XML, and supports XPath, schema validation, and has a generic post-processing engine. It can return events like SAX, build a tree like a DOM, or switch between modes within a document. It is capable of supporting thousands of sessions simultaneously, and because of its pipeline nature can process more than one character per clock tick. The talk will explain some of the features in the card and its device driver, such as memory usage and zero-copy, synchronization of QName identifiers between card and software, and the programmability.
This is the first time we've publically talked about the hardware, other than the patent. :)
RSalz 2700011QK0 447 Visits
RSalz 2700011QK0 505 Visits
There are many articles on the web about how to effectively write effective software for multi-core CPU's. A web search for multi-core, with or without the hyphen, will turn up millions of hits. One of the reasons for the interest is the thought that vendors might be reaching physical limits to Moore's Law, and are therefore turning to replication, moving from the single-core ear to the multi-core era. Those cores are all the same, so it's really the 'homogenous multi-core era.' If you're smart, just seeing that first word opens your mind up to the possibility of hybrid multi-core systems, where the CPU has built-in accelerators for special tasks, such as cryptography, XML, or whatever. (If you're really smart, you saw enough to add that word in the first place.) (Either way, you're smarter than me.)
As IT appliances are often deployed in specialized environments, such as the edge of the network, the possibilities seem particularly interesting.