By Bryan Jacobson, Linux Technology Center.

Tyler Hicks (from our team) recently attended the 5/25-29 Ubuntu Developers Summit for Karmic Koala in Barcelona, Spain.

Some of Tyler’s observations on Security topics:

• There are quite a few eCryptfs users out there and they are generally happy with the version shipped in Jaunty. Most were using the encrypted home feature, but some wanted more flexibility and had custom setups.
• eCryptfs encrypted swap is on the roadmap for Karmic.
• Michael Rooney has been working on graphical applications to compliment some of the eCryptfs userspace tools that are currently bound to the command line.
• Tyler held an eCryptfs roadmap talk about future eCryptfs features: eCryptfs on top of popular network filesystems, improved key management, and asking for someone interested in completing the eCryptfs GPG key module.

Some general observations from Tyler:

• Ubuntu would like to be the premier guest available in Amazon EC2.
• Ubuntu users will soon have a daily build of the virtualization stack available, which is a big win for both the upstream developers and the users.
• Dustin Kirkland http://blog.dustinkirkland.com/ gave a talk on leveraging the cloud for data center power savings.
• The Ubuntu kernel team committed to removing non-upstream kernel code that no one is using anymore.

See the whole story on Tyler blog at: http://blog.tyhicks.net

By Debora Velarde, IBM Linux Technology Center

Someone recently pointed me to a study on the Open Source Trusted Computing Software Stack which was sponsored by The German Federal Office for Information Security (BSI). The study titled “Introduction and Analysis of the Open Source TCG Software Stack TrouSerS and Tools in its Environment” was performed by Sirrix AG security technologies. The study is available in English from the BSI web site. Since the study was published on the BSI site a year ago, some of the information is a little outdated. But it is still a good read for anyone trying to understand the different components that make up the Trusted Computing Software Stack and the relationship between the different components.

The study covers many of components that I was already familiar with: TrustedGRUB [1], GRUB-IMA [2], the Linux TPM Device Driver [3], TrouSerS [4], TPM Tools [5], and the OpenSSL TPM Engine [6]. However, the study also covered some items that I hadn’t known about prior to reading the study: the Open Secure Loader (OSLO) and the TPM Manager. OSLO is a security enhanced bootloader that uses the Dynamic Root of Trust for Measurement [7]. TPM Manager is a graphical user interface for managing the TPM which Sirrix AG helped to develop [8]. One item the study does not cover is Hal Finney’s Privacy CA which Emily blogged about back in January of 2008. For each component included in the study, it provides an overview, some install and configuration information, and an analysis of the quality of the implementation. The quality analysis includes details such as: implementation language, lines of code, whether the code is well commented, available documentation and support such as mailing lists.

In the “Compliance and Interoperability” chapter, the study takes a look at each of the components focusing on their compliance with respect to different specifications. Next, the study includes results from testing the components interoperability with SELinux [9], the Xen hypervisor [10], and the Turaya security kernel [11]. If you’ve never heard of the Turaya security kernel, you’re not alone. Information about Turaya is available on the Sirrix AG web site.

In the final chapter, the study makes some conclusions about the Open Source Trusted Computing Software Stack. It states that “the most important building blocks” are “available and robust enough to be used in a wide variety of security-critical services and applications”. The study continues to note that there is currently no application that actually takes advantage of this trusted computing technology. The study also concludes that the results from the interoperability testing with SELinux, Xen, and Turaya, are “high enough to realize TC-enabled applications on top of them.” Finally, the study closes by discussing some open issues including suggestions for improvement.

Related Links:
[1] TrustedGRUB: https://sourceforge.net/projects/trustedgrub
[2] GRUB-IMA: http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html
[3] Linux TPM Device Driver: now part of the Linux kernel http://kernel.org/
[4] TrouSerS: https://sourceforge.net/projects/trousers/
[5] TPM Tools: https://sourceforge.net/projects/trousers/
[6] OpenSSL TPM Engine: https://sourceforge.net/project/showfiles.php?group_id=126012&package_id=165637
[7] Open Secure LOader: http://os.inf.tu-dresden.de/~kauer/oslo/
[8] TPM Manager: https://sourceforge.net/projects/tpmmanager/
[9] SELinux: http://www.nsa.gov/research/selinux/index.shtml
[10] Xen: http://www.xen.org/
[11] Turaya: http://www.sirrix.com/content/pages/50580.htm

I think this is great news for potential patent reform (long overdue). David certainly has experience with open source licensing and IP issues related to open development.

While many will see the press generalizations about David’s views on IP reform, why not listen to his interview with Scoble from August of 2007 and hear for yourself? In the interview David talks about collaborative innovation, open standards and open source which I think many will still find very interesting.

Scoble Interview: http://www.mefeedia.com/entry/3286371/

Ars covered the news here:

The Obama administration’s choice to head the US Patent and Trademark Office, IBM’s David Kappos, appears to be getting rave reviews, which can only partly be attributed to the fact that Kappos has been a prominent advocate of patent reform.

And this is a link to the official announcement.

http://www.whitehouse.gov/the_press_office/President-Obama-Announces-More-Key-Administration-Posts-6-18-09/

I recently installed Ubuntu Studio on a spare, many-years old system (a Pentium 3) to try out a new Edirol UA-25EX audio interface that I picked up. I plan to detail my experiences with Studio in a soon-to-come post, but there was one problem I ran into that warrants its own post. After applying a [...]

There's an advocacy piece, in Forbes of all places, that offers a pretty unbalanced perspective on Solaris. (I hesitate to even link to it, because it feels like sensationalism just to generate huge numbers of outraged readers.) The author, Dan Woods, doesn't mention any negative points to Solaris at all, which should raise the suspicions of any reader with critical thinking skills, but I wanted to debunk some of the virtualization statements in particular:

Dan claims that Linux virtualization is the result of un-coordinated development from a number of companies, and Solaris virtualization is better because it's engineered "top to bottom" at a single company. Seamless integration can certainly offer advantages (see Apple), but I take issue with both his observations about the ecosystem and the conclusions he draws from them.

Aside from containers, Solaris uses hypervisors from Xen (marketed as xVM), and VirtualBox (from the innotek acquisition). Neither of those solutions were designed for Solaris; they were adopted years later to fill gaps in Sun's offerings. However, they are currently developed by Sun, so you still have the "single company" argument. About that...

Where I come from, being completely dependent on a single company is a bad thing, and I'm not even talking about the freedom of open source. It's called "vendor lock-in," and it's bad because there's no competition and customers are at the mercy of that single company's roadmap. Companies invest lots of money developing and supporting 3rd party ecosystems because it's a critically important to their customers. Anyways, looking at it from another angle, isn't it disturbing that virtualization ISVs don't consider Solaris important enough to target? Sun had to buy them outright or develop solutions in-house.

Dan claims Solaris containers cause a 2% performance degradation, vs. "about 20% for a hypervisor." While it's true that Forbes isn't a good forum for presenting performance analyses, without even a hint about where they came from, offering these numbers is ridiculous. It's often true that you can pick a specific benchmark and environment to support any argument, but Dan didn't even pretend.

Finally, I thought Dan's most interesting claim was the one for which he didn't offer any supporting arguments at all: that Solaris is now safe. Even if he's right, and Solaris is indeed the most awesome OS ever seen, that still doesn't guarantee it a slot on the Oracle roadmap.

Yesterday Wind River Systems released the hypervisor they announced last summer, complete with YouTube videos:

• Release announcement
• Mark Hermeling's blog entry
  
• LinuxDevices coverage
• EETimes coverage

Things I find interesting:

• From the demo video, we can see that the x86 port uses VT, but the PowerPC core doesn't have equivalent functionality (e500v2 is pre-ISA 2.06). That must mean they've got a paravirtual interface, likely the "virtual board interface" mentioned.
• EETimes quote: "We map I/O into the guest environment directly so it can directly talk to data registers to get higher performance." Given that they're releasing VxWorks MILS Platform 2.0 today for the hypervisor, which presumably requires high levels of isolation, I'm willing to bet that direct IO access is an option rather than a design assumption.
  
• Mark's demo videos had an emphasis on their Workbench IDE. I don't know if this was a conscious decision or not, but it does nicely reinforce the notion of the hypervisor as part of a solution, not a standalone product.
• They advertise their "MIPC" shared-memory inter-guest communication mechansim. I hope they just put a fancy name on virtio, but I doubt it. If they aren't using virtio, they're developing yet another set of virtual IO drivers for Linux. :(
• Their Linux patch isn't mentioned, but I hope they will be publishing it and merging it upstream, instead of the usual RTOS vendor approach to Linux...
• They consistently advertise the performance impact as "2-3% at worst." That's a nice marketing bullet, but is never the right answer to a vague performance question. The right answer is "it depends." In this case, it depends on the processor model, the workload, the partitioning configuration, and more. For example, VT-enabled x86 virtualization will have very different performance characteristics than paravirtualized PowerPC.

All in all, it's a significant event when a dominant embedded software company enters a new area like virtualization. As time goes by, it will be interesting to see how well they play with competitors' software... who is going to port Integrity to the Wind River virtual board interface? ;)

The rcu_barrier() function was described some time back in an article on Linux Weekly News. This rcu_barrier() function solves the problem where a given module invokes call_rcu() using a function in that module, but the module is removed before the corresponding grace period elapses, or at least before the callback can be invoked. This results in an attempt to call a function whose code has been removed from the Linux kernel. Oops!!!

Since the above article was written, rcu_barrier_bh() and rcu_barrier_sched() have been accepted into the Linux kernel, for use with call_rcu_bh() and call_rcu_sched(), respectively. These functions have seen relatively little use, which is no surprise, given that they are quite specialized. However, Jesper Dangaard recently discovered that they need to be used a bit more heavily. This lead to the question of exactly when they needed to be used, to which I responded as follows:

Unless there is some other mechanism to ensure that all the RCU callbacks have been invoked before the module exit, there needs to be code in the module-exit function that does the following:

1. Prevents any new RCU callbacks from being posted. In other words, make sure that no future call_rcu() invocations happen from this module unless those call_rcu() invocations touch only functions and data that outlive this module.
   
2. Invokes rcu_barrier().
   
3. Of course, if the module uses call_rcu_sched() instead of call_rcu(), then it should invoke rcu_barrier_sched() instead of rcu_barrier(). Similarly, if it uses call_rcu_bh() instead of call_rcu(), then it should invoke rcu_barrier_bh() instead of rcu_barrier(). If the module uses more than one of call_rcu(), call_rcu_sched(), and call_rcu_bh(), then it must invoke more than one of rcu_barrier(), rcu_barrier_sched(), and rcu_barrier_bh().
   

What other mechanism could be used? I cannot think of one that it safe. For example, a module that tried to count the number of RCU callbacks in flight would be vulnerable to races as follows:

1. CPU 0: RCU callback decrements the counter.
   
2. CPU 1: module-exit function notices that the counter is zero, so removes the module.
   
3. CPU 0: attempts to execute the code returning from the RCU callback, and dies horribly due to that code no longer being in memory.
   

If there was an easy solution (or even a hard solution) to this problem, then I do not believe that Nikita Danilov would have asked Dipankar Sarma for rcu_barrier(). Therefore, I do not expect anyone to be able to come up with an alternative to rcu_barrier() and friends. Always happy to learn something by being proven wrong, of course!!!

So unless someone can show me some other safe mechanism, every unloadable module that uses call_rcu(), call_rcu_sched(), or call_rcu_bh() must use rcu_barrier(), rcu_barrier_sched(), and/or rcu_barrier_bh() in its module-exit function.

So if you have a module that uses one of the call_rcu() functions, please use the corresponding rcu_barrier() function in the module-exit code!

Update: Peter Zijlstra rightly points out that the issue is not whether your module invokes call_rcu(), but rather whether the corresponding RCU callback invokes a function is in a module. So, if there is a call_rcu(), call_rcu_sched(), or call_rcu_bh() anywhere in the kernel whose RCU callback either directly or indirectly invokes a function in your module, then your module's exit function needs to invoke code>rcu_barrier()</code>, rcu_barrier_sched(), and/or rcu_barrier_bh(). Thanks to Peter for pointing this out!

OK, this post is about virtual machines in the JVM sense, not in the hypervisor sense. (The lines are getting a little blurry these days though.)

Back in the day, I once installed Windows NT on an RS/6000 (PowerPC) just to play with it. (It's funny how obsolete/impractical technology seemed so interesting back then, and these days it boggles my mind how anybody could care about Haiku, Amiga, etc.) So Windows NT: it installed OK, I started it up, and ran IE 2.0. That sucked (even at the time), but there were no updates for it. I ran the bundled Pinball game. That was the end of the story, because there was no ISV support. Just porting the kernel wasn't enough: an x86 WinNT application still couldn't run on PowerPC WinNT. The same fate could befall ARM netbooks (ahem "smartbooks").

This post suggests that .NET could be the answer. It starts by assuming that ARM netbooks will be common (a question on which the jury is still out), and then assumes Microsoft will somehow want to participate in that ecosystem (probably a safe bet: look at Windows ME on phones). Port some Windows kernel to ARM netbooks, provide a .NET runtime, and then just run .NET applications -- never worry about needing native ARM Windows binaries.

That has an existing parallel of course: J2ME on mobile phones. As a consumer, I'd call that a success. I love that I can download a random Java application and not worry about if the creator has built it for N phone vendors x M models. I'm sure J2ME has its limits, but it has made my life better.

And of course Google is walking down the same path with Dalvik. The cool thing about Java/Dalvik/.NET that it might just allow another processor architecture to compete with Intel without the legacy software issue. It will be interesting to see if Intel eventually enables Java on Moblin.

With Intel investing so many resources not just into the Linux kernel, but now into a full mobile Linux distribution (complete with UI), maybe Microsoft will annoy them right back by enabling ARM netbooks. You know both of them have to be looking to embedded systems for growth.

Anyways, I'd only buy a netbook that runs Linux. ;) I've heard good things about the ARM instruction set...

Reader-writer locks can certainly cause problems if used carelessly, the problems including cache thrashing, write-side contention, and poor scaling. But it is a rare tool that does not have some jobs that it is good for, so it is reasonable to ask what types of jobs favor reader-writer locking.

First, it is important to note that if the reader-writer lock is used sufficiently infrequently, its overhead cannot possibly cause too much trouble. On most systems, if the critical sections are short and if the lock is not acquired more than a few tens of thousands of times per second, there should be no problem. On the other hand, if the lock must be acquired millions of times per second, you are likely to need to do something else. This “something else” might be partitioning the data protected by the reader-writer lock (thus reducing the per-lock acquisition frequency), or it might be some other tool. (Yes, yes, I might be expected to suggest RCU, and I might well do so, but reference counting, exclusive locks, and atomic operations are also possibilities.)

If the reader-writer lock is primarily read-acquired, and if it is read-held for a significant period of time, then reader-writer locking can again work quite well. However, the number of acquisitions per unit time is still important, and this number often rises with increasing numbers of CPUs. This effect can be seen in the following graph:



This graph was generated on a 64-core Power 5 system with two hardware threads per core for 128 hardware threads total. Each thread repeatedly:

1. read-acquired a pthread_rwlock_t,
   
2. took a fixed number of passes through a tight loop, and
   
3. released the rwlock_t.
   

In the “1K” trace, this fixed number of passes was 1,000, in the “10K” it was 10,000, and so on up to the “100M” trace, where the fixed number of passes was 100 million. Each point is computed by taking the ratio of the acquisitions per unit time for N threads divided by N times the acquisitions per unit time for a single thread. Ideal scaling would give 1.0.

As you can see, adding CPUs eventually causes performance to suffer, and the shorter the critical section, the greater the degree of suffering inflicted.

So, reader-writer locking can be the right tool for read-mostly jobs, at least when acquired sufficiently infrequently or if the read-side critical sections are sufficiently long. Just keep in mind that the value of “sufficiently” varies with the number of CPUs!

By: Bryan Jacobson (bryan.jacobson@us.ibm.com)    As always, the following are my personal opinions.

 

“Product X”

 I recently heard about an authentication product, let’s call it “Product X”.   According to their website:

Product X . . . implements the equivalent of a “one-time pad” system – the most secure communication possible.

Product X uses applied physics to defeat all known Internet authentication threats.

Sounds good, maybe too good.  Can we trust it?

 

Cryptographic Snake Oil

 

Serge Hallyn introduced me to the term “cryptographic snake oil”, which is explained at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html:

 

Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security.

 

Why “snake oil”? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor’s claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure just about any ailment that a potential customer could have. Listening to the claims made by some crypto vendors, “snake oil” is a surprisingly apt name.

 

The snake-oil-faq is a fun website with a lot of information.  Regarding “one-time-pads” it says: 

A vendor might claim the system uses a one-time-pad (OTP), which is provably unbreakable.

 

Snake oil vendors will try to capitalize on the known strength of an OTP. But it is important to understand that any variation in the implementation means that it is not an OTP and has nowhere near the security of an OTP.

 What are One-time-pads, and why are they “unbreakable”?

 A One-time-pad is a key as long as the message.  Each byte of the OTP is generated with an unpredictable random process. 

 The sender and receiver each need a copy of the OTP and must insure no one else has a copy. The OTP should be physically exchanged, not transmitted.

 Each byte of the OTP is only used once – so there is no “statistical pattern” that an adversary could use to crack the message.  (More info is at: http://en.wikipedia.org/wiki/One-time_pad.)

The unbreakability of one-time-pads rests on three factors:

1. Every byte in the OTP is generated by a truly random (unpredictable) process.

2. Every byte in the OTP is used only once.

3. The sender and recipient insure that no one else could have a copy of the pad.

When these are true, the OTP is unbreakable – there is no vulnerability that can be exploited.

 

How Product X works (I think)

Note: This is not a comprehensive evaluation of “Product X”, but rather my personal quick comparison of the  information on their website to One-time-pads.  Their website does not have a complete technical description, so I’ve made some assumptions that could be inaccurate.

 If I understand correctly, “Product X” works like this:

 - “Product X” uses a USB device and some software to provide secure authentication (login) from the user’s client system to a remote server.

- The user supplies a User ID and a Password on the client system.

- The User ID is sent to the server software, which selects an “index” that is sent back to the client.

- The “index” and secure information in the USB device create a “one-time password”, claimed to be equivalent to a One-time-pad.

- The “one-time password” is used to securely transmit the User’s password to the server.

 

Is “Product X” the equivalent of a one-time-pad?

 Let’s look at the factors that make one-time-pads unbreakable:

1. Every byte in the OTP is unpredictable.

I will assume they got this right.   You can use random.org, or several other techniques.

2. Every byte in the OTP is used only once.

I don’t think this is the case.  I believe the “index” sent back from the server, works with the USB device to “randomly” select a pad.  If enough logins happen, eventually pads will get re-used.

The Snake Oil website says:

OTPs are seriously vulnerable if you ever reuse a pad. For instance, the NSA’s VENONA project [4], without the benefit of computer assistance, managed to decrypt a series of KGB messages encrypted with faulty pads. It doesn’t take much work to crack a reused pad.

How soon are pads reused?  The “Product X” website mentions “billions”, but doesn’t give specifics.

3. The sender and recipient insure that no one else could have a copy of the pad.

I don’t think this is the case.  I believe all users share the same set of pads (otherwise the remote server would need a huge amount of per-user data).

However, I believe the role of the USB Device is to scrambles the pad selection on a per-user basis.  I think security experts agree – a device like this (assuming well implemented) with a physically secure secret, provides significant security advantages.

So, the strength of “Product X” is based on:

- Could an adversary detect re-use of a pad?

- Could an adversary subvert the secret in the USB device?

This is the point of the “Snake Oil” FAQ.  The strength of “Product X” is based on its own implementation details – not the “unbreakable” strength of one-time-pads.

 

I hope users of “Product X” also understand that it  *ONLY* provides special security for the authentication step (the communication of the password).   It does not help with the rest of the communication between the client and the server.

 

Since One-time-pads are so dang secure, why aren’t they used for everything?

OTPs have two important limitations:

- They must not be reused, and need to have as many bytes as the messages they are encoding.  This is not practical if you’ve got gigabytes going back and forth every day.

- There must be some other secure mechanism to get the pad from one party to the other.  That’s hard to do if you’re communicating with someone you’ve never met before (common on the web).

 

The Snake Oil FAQ lists many other things to watch out for, such as:

• Secret Algorithms
• Revolutionary Breakthroughs
• Experienced Security Experts, Rave Reviews, and Other Useless Certificates

Linux Plumbers Conference is making great progress!

Linus Torvalds has graciously agreed to give an advanced git tutorial, Keith Packard has agreed to give one of the keynotes, and Vivek Kundra (Federal CIO) has agreed to be listed as an invitee (to be confirmed) for a live-video keynote presentation with read-time Q&A. Kudos to all the people whose hard work and persistence has made all this possible!

Watching submissions to software-related conferences is normally a bit of a nail-biting exercise, but for this year's Linux Plumbers Conference, it has actually been quite fun! We have quite a few extremely promising submissions—a big "thank you!!!" to all the submitters!

However, there is one potential problem with the submissions thus far. What problem might that be? Well, unless you have already submitted an abstract, we haven't heard from you yet!!! There is a bit more than two weeks left before the deadline, and I hope you come up with a good topic and submit an abstract. After all, the program committee cannot possibly accept your abstract unless you submit it!!!

[jk@pingu ~]$ mkdir ~/sshfs
[jk@pingu ~]$ afuse -o mount_template="sshfs %r:/ %m" -o unmount_template="fusermount -u -z %m" ~/sshfs/
[jk@pingu ~]$ cat ~/sshfs/ozlabs.org/etc/hostname
ozlabs
[jk@pingu ~]$ 

Oracle made headlines for two acqusitions in the past month, Sun and Virtual Iron. By my count, that makes them the proud owners of no fewer than four x86 hypervisors: Oracle VM, Sun's xVM Server, Sun's xVM Desktop (a.k.a. VirtualBox), and Virtual Iron. (I've never really understood why Sun had two.) All but VirtualBox are based on Xen.

Even with this surprising success in the game of "collect the Xen implementations," that still leaves at least Red Hat, Novell, and of course Citrix itself offering competing Xen solutions. I'll admit the Unix wars predate me, but that seems like an impressive degree of fragmentation. Still, Red Hat has announced plans to abandon Xen for KVM, and even Novell included KVM as a tech preview in SLES11. There's no question that the number of Xen-based products is about to significantly shrink.

I've even seen one person speculate that the cost of maintaining Xen is so high, that with Red Hat pulling out, Oracle must have been worried about strengthening their Xen development capabilities.

What's worse though is that each of those Oracle hypervisors has its own management stack. Systems management is one of those areas that sounds really easy, but in practice never is. Management software contains so many layers that it's hard to find anybody who actually understands the end-to-end details of a particular code path. You need translation layers for components that are too old, too new, or fit at a different layer, or written for a different management stack. In this case, you might find one management stack built on xm, another built on libvirt, another built on CIM (and "enterprise frameworks" are a whole other world of complexity). Do they use OVF for image files? Should they? Every design question has tradeoffs and requires serious consideration.

Speaking from experience at a large company, I expect there will be at least 6 months of churn while architects furiously scribe presentations, rearrange block diagrams, create hypothetical development sizings, establish migration plans for legacy customers, escalate issues to management (which will be sorting itself out too), find and get input from related organizations ("how does this affect our relationship with VMware?"), and in general figure out what they're doing. After all the dust has settled, they'll still need to write the code.

Will the eventual result of this consolidation be a stronger Xen ecosystem a few years from now? To be honest, I couldn't care less... but it could be worth the cost of a bag of popcorn.

Mathieu Desnoyers's user-level RCU implementation has now been relicensed under LGPL! This is available at git://lttng.org/userspace-rcu.git, as before.

The May issue of Communications of the ACM has a page of puzzles at the end, the first of which involves a colony of 54 chameleons, of which 20 are red, 18 are blue, and 16 are green. Should a pair of chameleons of different colors meet, they both turn to the other color, so that if a red and a blue chameleon meet, both will turn green. Assuming no births or deaths, is there a sequence of meetings that results in all the chameleons being the same color?

It turns out that you can abuse Promela to solve this problem, although I am sure that the puzzle creator had something else in mind! See here for the Promela code and here for the output.

The way that the model is set up, zero “errors” indicates that the goal cannot be reached. You can of course tweak the initial values of the r, b, and g variables to see if other colonies could go monochrome.

I've wondered how "WAN optimization" magic works, and I just came across a page to explain it in (a little) more detail than marketing. I hadn't heard of it until a couple years ago, when some Cisco people mentioned that their WAASrouters embed KVM for virtualization.

Why would they do that? Because if your branch office uses an Active Directory server in your centralized data center, and your WAN link dies, work at the branch office ceases. From what I understand, Cisco's WAAS routers run an Active Directory server inside a virtual machine on the router itself, to mitigate that problem. A little googling reveals that similar approaches may be taken by their competition, 3Com and Riverbed.

In general, I expect we'll see much more virtualization in this area in the future. For example, today Cisco's Application Extension Platform (AXP) products are physical x86 cards you stick into a router to run server workloads. It would be plain silly not to take advantage of the well-known consolidation benefits of virtualization to accomplish the same thing. (That's pure speculation, but as I said... silly.)

Intel has done a study on the costs associated with a stolen or lost laptop. One of the most interesting aspects of the study is that they were able to quantify how much a company saves when the confidential data on the lost laptop is encrypted. The grand total is

$18,722

saved per lost laptop when the confidential data is encrypted.

I’d recommend using eCryptfs if you are running Linux on your laptop.

by Klaus Heinrich Kiwi, IBM LTC Security Team.

In the Information Security world, authentication and authorization are orthogonal concepts:

• Authentication refers to the act of correctly identifying an user or other entity, e.g.: making sure a user is who he really say he is. This is often done by associating passwords or keys to user accounts.
• Authorization refers to the act of granting access from certain users to certain services or resources, e.g.: allowing the user john_doe to read the file /foo/bar. This is usually done by mapping users and groups to resources through the use of permissions.

Kerberos is a network authentication protocol aimed at providing secure and reliable authentication semantics over an insecure (open) network. In a glimpse, it relies on symmetric key cryptography and in a trusted third-party to provide mutual authentication between two entities (called Principals in Kerberos nomenclature). This means that in a scenario where a user is authenticated against a network service, not only the service can be sure of the user identity, but the user can also be sure that he is communicating with the right server. All of this is done without exposing clear passwords or keys in the network.

The Kerberos Protocol is a standard (RFC 4120) with different implementations such as Microsoft’s Active Directory, Heimdal, the AFS kaserver and the Open Source MIT-Kerberos implementation.

LDAP, on the other hand, is an information retrieval protocol for accessing special purpose databases, called Directories. Directories are usually optimized for reading (queries) as opposed to writing operations (inserts), thus they are often used in write once, read many scenarios. This optimization aspect, associated with the hierarchical manner the objects are organized in the database makes LDAP an ideal choice for performing the mapping operations an authorization system needs.

LDAP is also a standard (RFC 4510, RFC 3494 among others) with numerous implementations such as the Open Source OpenLDAP and the IBM Tivoli Directory Server, aimed at enterprise use.

Since release 1.6 of the Open Source MIT-Kerberos (krb5) implementation, it is possible to combine the powerful authentication aspects of the Kerberos Protocol with the reliability and scalability provided by LDAP authorization. Such feature is included in recent enterprise distributions like Red Hat Enterprise Linux 5 series and Novell SUSE Linux Enterprise Server 11 and later, giving those platforms the possibility to benefit from combining the Open Source MIT-Kerberos implementation with the enterprise features of IBM Tivoli Directory Server.

It was with the intention of demonstrating how the above scenario can be achieved that I wrote a Blueprint covering the subject of Using MIT-Kerberos fo IBM Tivoli Directory Server backend.

Blueprints are documents describing the detailed plan of action for a specific task involving IBM hardware or technology. Blueprints bring a step-by-step description showing the exact actions needed to perform a certain task. Those steps are written with the expertise from the Software Engineers who actually work on development, but are also tested for correctness inside IBM labs – an IBM-branded HOWTO.

Besides the above Blueprint, please check-out the other publications I’ve authored or co-authored, including the Enterprise Multiplatform Auditing Redbook and  my Logical Volume Management developerWorks article.

And as always, feedback is greatly appreciated!

-Klaus Kiwi