Icon 7614 shocks arrive damaged

May 31, 2011 ~ flihp ~ Leave a comment

After trying a set of KYBs from a Kawasaki ZRX and finding them too big to fit under my Predator exhaust I started looking for a set of shocks with a lower profile. I found these Icon 7614s on the NewThruxton.com. They don’t have all of the adjustments that the KYBs do but they definitely look thin enough to fit under my exhaust and they’re a lot lighter weight.

They arrived two weeks ago but I’ve been traveling for work and just got around to putting them on today. In the photo above they look great but when I unboxed them I noticed some damage on the springs. The damage is super obvious up close. I can only speculate how they were damaged but it probably happened before they were assembled because the rest of the shock body is perfect. But the plastic coating on the springs on both shocks is scratched down to the metal in a few spots. Here’s what I’m talking about:

The damage looks like they rubbed up against something. The reflection of the lights makes it a bit difficult to see at first but I’ve rotated the shock to the left a bit to offset the reflection. I’ve marked up the place where the plastic coating was stripped down to the metal underneath and provided a good close-up. Looking further down the spring you’ll see other places where the plastic was stripped away and there are a few where it’s gone through to the metal.

What a pain. I was really excited to get these on. Even worse than having to go through returning them is that I probably won’t have them on my bike for my upcoming ride up route 100 through Vermont. Not much I can do now but try to get NewThruxton.com to take them back. Not happy.

UPDATE: Added better photo.

Kawasaki ZRX KYB shocks on ’04 Thruxton

May 30, 2011 ~ flihp ~ 2 Comments

I spent some time recently searching for a new set of shocks for my Thruxton. I’ve made a number of performance upgrades but I’ve kept the stock shocks in place even though they’re pretty crappy. There’s a lot of options for this upgrade so hopefully my experience will be useful to someone out there weighting the same decisions.

First a shot of the stock shocks before I removed them. Notice the corrosion showing on the bottom. Luckily it was from the bolt, not the mount.

First I tried used set taken of KYBs taken from a Kawasaki ZRX 1100. These are a pretty common upgrade for Thruxtons even though the ZRX is much heavier. In the end the reports I’ve read indicated the ride was nice if a bit stiff.

The shocks were the right size but the bottom bushings that came in the shocks were the wrong size. Not a hard fix since the stock shock bushing were easy enough to knock out with a mallet and socket. After fitting these in the KYBs they were easy enough to mount on the bike now that I’ve got a lift. Here’s a shot of the bushings taken from the stock shocks, and the KYBs mounted. Check out the super nice dress-up bolts I got from Joker Machines too.

They look really slick but unfortunately I couldn’t keep them. The coils on the KYB shocks are significantly wider than the stock Thruxton shocks. This came into play when I tried to fit my exhaust back on as the final step. I’ve got a set of Predators from British Customs and these cans are just too wide to fit over the ZRX shocks. Damn.

I really like these shocks and I thought about getting a new exhaust to fit over them. Then I remembered how I love the sound from the Predators so I’m still searching. I picked up a set of Icons and I’ll post about that disaster next.

Understanding Multi-Level Security Part 1

May 23, 2011 ~ flihp ~ 1 Comment

In my last post I introduced a topic I’ve been working on over the past year. That post provided a description of the problem and it’s importance, but didn’t get into the details behind the technologies used in the solution I’ve worked up. This post is the first of several to come that will fill in these details.

Purpose

I’ve been having a hard time sorting out the best way to present the relatively complex topic of computer security policy and it’s application to my specific project. My first few attempts to write this up resulted in some very convoluted ramblings.

It seemed like I was starting in the middle and missing all the background. Hoping to fix this I’m starting from the beginning with a quick explanation of the security policy that’s at the core of my project: military security policies and their implementation in SELinux.

To explain this I’m using a logical framework put forward by Chin and Older in their recent book [1]. I took a class with Dr. Chin this past fall and was particularly impressed with the contents of the book and the clear, concise syntax they developed.

Classifications

Everyone who’s seen a good spy movie has heard references to military security policy. I think it’s safe to day that every James Bond or Jason Bourne movie made a few references to Unclassified, Secret or Top Secret data. These are typically referred to as classifications or sensitivity levels in the literature. Everyone who’s seen these movies understands what the policy is, but few people have a solid grasp on the mathematical rules that govern access control systems implementing this policy.

It really is as simple as it seams though and easy to explain in the context of subjects (generally people or computer processes acting on their behalf) and objects (either physical or electronic). There are two governing principles [2]:

the simple security property: a subject operating at a given sensitivity level can read objects at the same level or below
the ★-property: a subject operating at a given sensitivity level can write to objects at the same level or higher

A computer system that implements these two rules is said to implement a multi-level security (MLS) policy.

Inherent in these two rules is a partial ordering among classification labels. Chin and Older describe this ordering by first defining a function that produces the sensitivity of a principle or object: $slev (X)$ . For a given object O that is classified Secret we would say:

$ slev (O) = Secret $

They also define an operator: $le_{s}$ that describes the relationship between two sensitivity levels. Going back to the sensitivity levels we’re so familiar with we would say:

$ Unclass le_{s} Secret le_{s} TopSecret $

Simply put a TopSecret principle is more sensitive than (or dominates) a Secret principle, which dominates an $Unclass$ principle. Combining these two operators we can now describe these relationships in an access control scenario.

The Simple Security Property

Getting back to the security properties for military data we can use the above syntax to describe the system. The simple security property requires that a subject operating at a given security level can read objects at the same level or below. We’d such a situation as:

$ (slev (O) le_{s} slev (S)) supset read $

Above we assume the ‘O’ and ‘S’ are an object and a subject in our system respectively. By the definition of $slev ()$ we know it returns the sensitivity level of its parameter so let’s say that object O is classified Secret and subject S is classified Top Secret. We could then say:

$ (S le_{s} TS) supset read $

Knowing that $S le_{s} TS$ is true by the ordering we’ve defined and our knowledge of logical implication (modus ponens WHAT!) we can deduce $read$ from this for future use in our logical framework and we take this to mean a read operation would be granted. Chin and Older provide a more rigorous approach but for our purposes the short hand I’m using is sufficient (because I say so).

The ★-Property

The ★-property requires that the sensitivity level of a subject is lower than or equal to that of the object for a write access to be permitted. We’d represent this as:

$ (slev (S) le_{s} slev (O)) supset write $

If ‘S’ and ‘O’ are the same subject and object as in the previous example the values of $slev (S)$ and $slev (O)$ will again be top secret and secret respectively. Thus:

$ TS le_{s} S supset write $

Using the same partial ordering defined previously we can see that the first part of the implication here is false. This time from our knowledge of logical implication we can’t say anything about the term on the right (the $write$ statement), so we cannot say a write would be granted. It would then be denied by any sane access control implementation. Again I’m using short hand.

Conclusion

This brief introduction was an attempt to frame basic MLS constructs in a simple logic developed by Chin and Older. Alone this post won’t mean much to most people but it’s intended as a foundation. In my next post I’ll introduce SELinux constraints, MLS constraints and use the logic from this post to illustrate how a reference monitor would evaluate constraints in an access control decision.

References

1 Chin, Shiu-Kai and Older, Susan. Access Control, Security and Trust CRC Press, 2011.
2 Bell, David Elliott and LaPadula, Leonard J. Secure Computer Systems: A Mathematical Model, MITRE Corporation, 1973.
3 Chad Hanson, SELinux and MLS: Putting the Pieces Together, TCS

Thruxton ignition relocation

May 15, 2011 ~ flihp ~ Leave a comment

The weather’s starting to get nice and since I don’t have a garage to work in over the winter, I had to wait for nice weather to work on my Thruxton … in my driveway. Joker Machine makes some really nice bolt-ons and they’re pretty spendy so over the winter I picked up a few when I had a buck or two kicking around. A few days back when it finally hit 65 degrees outside I put on my ignition relocation kit.

The ignition location is a common complaint from Thruxton owners. It’s located on the headlight mount which is a bit odd, but really I’ve become used to it by now:

The relocation kit uses two bolts on the front of the frame as the anchor for the new bracket:

Removing the ignition is simple but it does require removing the headlight bracket to access the screws holding it in place:

After removing the ignition the fun begins. You can’t simply attach the new bracket with the existing cable. There just isn’t enough of it.

The ignition wires hook up to the main harness at a plug that’s housed in the headlight bucket. Actually just about everything that hooks up to the harness on the front end of the bike does so in the headlight bucket. So there are basically two options:

extend the ignition wires
cut into the harness and hope there’s enough wire in there to get the ignition to its new home

I went for the second option because I only needed a few extra inches of wire but it came at a cost: I couldn’t keep the connector between the ignition and the wiring harness in the headlight bucket. Here’s a shot of the harness with the cuts I had to make:

After that, wrap up the harness with electrical tape and stuff the connector up under the frame. Be sure to clean off the harness before you put the tape on it. Dirt makes tape pretty ineffective:

In the end it’ll look pretty cool:

The new location for the ignition isn’t any more convenient than the original if you ask me. Looks cool though.

Route from Syracuse to Laconia

May 10, 2011 ~ flihp ~ Leave a comment

It’s getting close bike week in Laconia NH and I’m planning out another route from Syracuse NY to the event (ending point is Alton Bay). Previously I’ve made a run straight across using major highways (boring and dangerous) and a much more fun route through Vermont down route 100. This year I’m planning to re-create the Vermont route but hopefully over two days.

First off here’s the route I took with an old room mate back in 2009. It’s as long as it looks. With a stop for lunch it took us about 10 hours.

This year I’m shooting for a stop in western Massachusetts at a buddy’s house. I figure this will cut the route in two and make for a much more enjoyable route through Vermont. In 2009 by the time we reached routes 17 and 100 in VT we were almost too tired to enjoy it. I’m really looking forward to the switch-backs on 17 when I’m not half dead.

Another Go at My Masters Project

May 8, 2011 ~ flihp ~ 2 Comments

About a year ago I started working on my masters project. The topic turned out to be … not interesting enough to hold my attention I guess. This ended up being for the best since shortly after losing interest in my first project I got picked up on a project at work that I managed to dual-purpose for both work and school. I’m at a point where all I need to do to graduate is write this work up.

This first post (with a new tag) is a brief introduction of what this work is and why you should care. Future posts on this topic will cover the technical background and an implementation, both a simulation and code targeted at a specific Xen-based platform.

SELinux and Virtualization

I’ve been playing with SELinux for a while now and more recently I’ve had the need to work with the Xen hypervisor. Specifically I’ve been tasked with getting an SELinux policy running in the management VM (a.k.a. dom0). Most people savvy on SELinux would simply use a Linux distro that supports SELinux out of the box as their dom0 like Debian, Fedora, CentOS / RedHat. This is a valid argument but a minimal Debian install has a root file system that’s about about a gigabyte in size and this was too big for our purposes.

The project was actually in full swing when I was tasked with SELinux integration and the team had already rolled their own dom0 using openembedded [1]. Getting SELinux up and running on an OE system was a pain but it’s done and that work isn’t all that interesting. What was interesting was implementing some policy and machinery to separate the instances of QEMU [2] that provide emulation for the HVM Windows guests [3].

SELinux does a great job of formalizing the interactions between processes. Any interactions that aren’t specified are prevented. I won’t go into a detailed explanation of the SELinux policy language [4] or Domain and Type Enforcement [5]. These are well documented elsewhere [6].

The Problem

What’s interesting is that on an SELinux system each process runs with a label defined by the label of it’s parent (the process that caused the execution) and the label on the programs binary file on disk. This means that a process performing multiple fork/exec calls on the same binary will produce child processes all with the same SELinux label. Under nearly all circumstances this is the desired effect. On our specific platform there is a case where this isn’t what we want.

As our platform is Xen, xend is the daemon responsible for managing VMs. When xend starts an HVM client it executes QEMU. This causes all QEMU instances running to have the same SELinux label. In SELinux speak we would say these QEMU instances are all running “in the same domain” which is equivalent to them all having the same permissions, or more precisely, the same access to system resources.

At this point understanding the separation goals of Xen is important. Where an OS kernel aims to keep running processes separate, Xen aims to keep running VMs separate. Having instances of QEMU operating on behalf of what are effectively untrusted client VMs all with the same SELinux label undermines this goal of separation.

Separating QEMU Instances

The sVirt [7] project specifically addressed this problem with a prototype implementation some time back. Eventually this was integrated with libvirt so if you’re running libvirt[8] with the SELinux security driver[9] loaded then presumably you’ve got these protections in place. But again due to the embedded nature of our dom0 libvirt was way more software than we needed.

It became necessary to implement the basic sVirt design but integrated directly into our management stack. This isn’t a line-for-line re-implementation of the libvirt SELinux code though. I’ve made a number of changes that I will discuss in detail in the following posts though the design goals remain the same: keep instances of QEMU separate. The metric we’re using to judge the usefulness of this work is our answer to the question “what could a compromised QEMU instance access?”. If the answer to this is “all of the virtual hard disks on the system” then obviously we’ve failed. Instead we’re aiming to confine a QEMU instance to the resources it needs to function, like the virtual disks belonging to the VM it is providing services to.

Next Time

Now that the basic problem is laid out the next step is to cover some background.
In my next post I’ll cover the background necessary to understand the specific pieces of the SELinux policy that this work uses to achieve these goals: the MCS policy.

References

1 the Open Embedded project: http://www.openembedded.org/index.php/Main_Page
2 the QEMU project: http://wiki.qemu.org/Main_Page
3 Xen-HVM: http://en.wikipedia.org/wiki/QEMU#Xen-HVM
4 SELinux policy language: http://selinuxproject.org/page/PolicyLanguage
5 Practical Domain and Type Enforcement for UNIX: http://portal.acm.org/citation.cfm?id=882491.884237
6 SELinux By Example: http://www.informit.com/store/product.aspx?isbn=0131963694
7 sVirt Requirements Document: http://selinuxproject.org/page/Svirt_requirements_v1.0
8 The libvirt Project: http://libvirt.org/
9 libvirt SELinux Driver: http://libvirt.org/drvqemu.html#securitysvirt