Mosfet R/R on Triumph Thruxton

A while back the charging system on my Thruxton started failing. I found this out one morning while I was a few hundred miles from home in New Hampshire, my bike wouldn’t turn over. Luckily the place I was staying had a battery charger (dumb luck) and a few hours later my battery was back to full power. My battery then began to die slowly but it got me through the rest of the trip.

At first I didn’t get what was going on. Really I just through my battery was dying but after poking around in some forums I got a tip to fire up my bike and check the voltage that my charging system was putting out. It should put out around 14 volts but it was only putting out 11.5V.

This is a sure sign that either the magnets on your stator is bad (this never happens from what I’m told) or your regulator / rectifier (R/R) is dead. A little more research turned up that the stock R/R on Triumphs are rubbish and generally fail after a few years. Replacing the stock R/R is a pretty standard upgrade on lots of bikes.

There’s a number of after market R/Rs to chose from. I found a few guys who had good results with a Msofet R/R. There’s even a guy that sells kits for the upgrade at roadstercycle. The instructions on the roadstercycle site aren’t very detailed so I figured it might be useful to have a detailed howto (aka lots of pictures) for those like myself new to doing electrical work on their bikes.


The installation has two main parts:

  • First is preparing all the wiring: attaching the connectors from the kit to the existing wires from your stator and the power/ground wires provided in the kit as well as running the power and ground wires to your battery.
  • Second is finding a place to mount your new R/R on your bike. Depending on your bike this may be very easy or very difficult so YMMV.

I started with the wiring because mounting stuff on your bike is usually pretty permanent. This typically involves drilling / cutting and if something goes wrong and the new R/R doesn’t work you’re stuck.


So the kit ships with these really fancy waterproof connectors that match up with the connectors on the R/R. There are two of them and they both accomodate 3 wires but one has the center hole plugged. This one is for the power and ground that will attach to your battery. The connector with the three holes open is for the three wires from your stator.

I started with the stator wires. They’re located at the engine casing on the right side of the bike. Follow them up to the connector where they hitch up to the wiring harness. On the Thruxton this is a 3 pronged connector and the three stator wires are bundled together in a black casing.
Sorry for the picture quality (focus is way off). I’m still trying to get the hang of of this new phone.

Cut these three wires right at the connectors to keep as much wire available as possible. You’ll have to run these to the new R/R wherever you decide to mount it. Once the old connector is off, you’ve got to put the new connector on.

The kit provides a bunch of crimp-on connectors:

You’ve got to:

  1. Strip about an inch off the wires casing
  2. Slip one of the provided water seals on the wire. This will be used to plug up the hole in the back of the connector.
  3. Slip on a bit of shrink tube. My stator wires were too thin for a good seal with the plugs so I put on some shrink tube to fill the gap.
  4. Fold the exposed wire in half to give yourself enough surface to crimp the connector
  5. Crimp on the connector, you can even throw a bit of solder on too if you’d like but it’s not necessary.
  6. Slip the shrink tube up over the crimp and shrink it down
  7. Slip the water seal up over the shrink tube

Do this for each wire

Then slip the three stator wires into the back of the connector. Make sure to press each water seal into the connector. If the fit is tight grab some silicon and lube up the rubber plugs.
I’m not sure I put the rubber plugs on in the right direction but the seal will work either way. I switched the direction when I put together the plug for power and ground.

Then do the same thing for the power and ground wires. These wires are much bigger (10 or 12 gauge) so I didn’t use shrink tube this time. Also the rubber stoppers were much more difficult to fit into the connector so keep your silicon handy.

Next you’ve gotta wire the fuse provided in the kit into your new power line and put the provided ring connectors on both power and ground. Nothing special here.

By this point you should have your stator wires set up with the new plug, the power and ground wired into the other plug, and the new power and ground wires ready to hook up to your battery.

Mounting the R/R

With your wires done you can start thinking about where you want to mount the R/R. Be sure you’ve got enough wire to reach the R/R wherever you mount it. BUT FIRST you should test the R/R to be sure the thing works.

Plug in those connectors you just put together, connect the power and ground to your battery and fire up your bike. The voltage across your battery should be between 14V and 14.5V.

If the voltage is right get ready to mount the R/R … if it’s not, well you screwed something up. Sorry. Break out your debugging gear and get to work. Hopefully you just screwed up a connection and you’ll find it quickly.

Once you’ve verified the R/R works pick out your mounting location. I installed a fender elimination kit (FEK) from a few years back. They still sell a kit but it’s significantly different from the one I bought. Regardless the battery box from the kit has a piece of metal hanging off the bottom to act as a sort of mud guard. The inside (toward the engine, away from the rear wheel) of this is just the right size and location to mount the new R/R.

The Mosfet kit doesn’t come with mounting hardware so you’ll need to pick up some up. I got mine at the hardware store down the block. I think the bolts were 6mm but I can’t remember. Just bring the R/R into the hardware store with you and try the hardware before you buy it. I picked up some lock-washers too for good measure.

Next I drilled the holes in my battery box. It’s impossible to get a drill into the right place without pulling off the wheel and going in through the rear. Remember, measure twice and drill once. Then mount the R/R, run the power and ground wires up to your battery and you’re done.

If you want to get fancy you can secure them with some zip ties. In the pictures you’ll see I haven’t got around to that yet.

Clean up

The stock R/R on the Thruxton is mounted on the front of the bike below the headlight on the same bracket as the blinkers. This is pretty much on the opposite end of the bike as the battery and the stator wires. This means that the stator wires run into the wiring harness back by the battery and extend to the front of the bike to plug into the R/R. The power and ground wires then come out of the R/R to the wiring harness and run back to the other end of the bike where they plug into the battery.

This is completely insane IMHO. You’ll notice I didn’t use any of the existing wire in the harness. All I did was snip the stator wire and tape up the old wire leaving the harness alone. Cutting into the wiring harness should be avoided at all cost. You can do the same to the stock R/R on the front of the bike. Just cut it off and tape up the wires.

Good luck.

2011 ride up Vermont route 100

My vacation last week was spent on the road riding with a few buddies. The highlight was definitely the ride out to Bike Week. We spent the night in Wilminton VT, rode up route 100 to 17, then back down to 89 then on to Alton Bay … with a stop at the Broken Spoke Saloon first naturally.

Here’s the route. In the less than perfect weather it took us about 12 hours including stops but it was worth every muscle ache and every minute in the saddle.

Understanding Multi-Level Security part 2

In my last post I gave a brief description of the two governing principles of Multi-Level security. I then used a short-hand version of a logical framework from Chin and Older to explain how a reference monitor may use such a logic to make access control decisions.

In this post I go one step further to look at the MLS component of SELinux policy. I’ll relate the MLS constraints from SELinux to the logical framework from Chin and Older and show how I’ve used their syntax to help debug SELinux denials (AVC denied) in my own policy writing.


The type enforcement (TE) model implemented in SELinux is very different from that of the MLS model. TE is a completely different approach to confining subjects and objects. Interesting enough though, to remain relevant in the government space (i.e. to get Common Critieria certified at the EAL4 level against the LSPP), SELinux was extended with the mechanisms necessary to implement an MLS policy. A significant portion of this work was done by TCS and is documented in a brief white-paper [1].

This paper describes the changes to the SELinux implementation in the kernel that were necessary, but assumes the reader is intimately familiar with government security policy. To fill that gap I’ve taken the logical rules from Chin and Older described previously and used them to explain the constraints that implement the MLS policy in SELinux.

SELinux Constraints

WE’ll start with a brief description of the SELinux constraint syntax. The interested reader I’ll refer the to the base constraint file in the SELinux source tree: $SELINUX_SRC/policy/constraints. In short, constraints allow for the policy author to define additional rules that must be satisfied beyond the SELinux type enforcement policy.

Let’s start with a simple example:

constrain dir_file_class_set { create relabelto relabelfrom } 
	u1 == u2
	or t1 == can_change_object_identity

The first keyword is constrain which simply identifies the constraint. Next comes a set of object types, followed by a set of permissions. When making an access control decision the security server will look at the requested permission and the object type and if they both are members of these sets the constraint will be evaluated. The constraint itself is a simple set of logical expressions. The parameters available for use in these expressions are the user, role and type component of the labels of both subject and object in the request. Components of the subject label are suffixed with 1, objects with 2.

In the expression above we see that the constraint requires that for a file or directory to be created or relabeled the user component of the subject and object labels cannot change (thus they must be equal or ==).
ASIDE: This constraint may seem like a mundane detail but it’s actually quite significant. Historically UNIX operating systems allowed users with sufficient privileges to change their identity to that of another user to perform administrative tasks. This constraint says that SELinux will never allow the user to change their identity (in the SELinux context) making attribution possible.

Examining the constraint further we see there is a loop hole that allows a subject with a specific type attribute (can_change_object_identity in this case) to change the user identity on a file or directory. Loop holes like this are unfortunate but are required for real systems to function.

MLS Constraints

The rules for MLS Constraints are the same as standard constraints. The only differences are:

  • subject and object labels available for use have the additional MLS label components
  • new operators which allow for the comparison of sensitivity labels

The MLS components of the SELinux labels come in two parts: the low clearance and the high clearance. These are pretty self explanatory as they represent the lowest possible clearance for a principle and the highest clearance the principle may access.
The new operators are:

  1. eq: two MLS label components are equal
  2. dom: one MLS label component dominates another
  3. domby; same as dom but reversed
  4. incomp: two MLS label components are incomparable

I’ll explain the important operators as well as an essential MLS property with an example:

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute }
	(( l1 dom l2 ) or
	 (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
	 ( t1 == mlsfileread ) or
	 ( t2 == mlstrustedobject ));

This rule constraints read operations on a rather large set of object types. The first line of the statement is the expected simple security property: the low clearance of the subject must dominate the low clearance of the object. Simply put this allows subjects to read at or below their lowest clearance.

The second line allows a subject to read an object if it’s highest clearance dominates that of the object AND it’s type is that of ‘mlsfilereadtoclr’ which is short hand for ‘mls file read to clearance’. This is a special set of subjects that are allowed to read to their highest clearance if they’re operating with a ranged label. Most processes will run with only one MLS label so this constraint will rarely come into play except for processes like init.

The remainig two lines are again, types that allow for loop holes. A process with this type would be considered a “trusted process” in the literature which basically means it’s a process allowed to violate the security model. We’d prefer to have none of these if possible but they exist for a number of reasons. These could be poorly coded software that can’t be fixed by those who care about these things because they’re proprietary or they’re simply processes that must violate MLS to perform their task.

Evaluating MLS Constraints in the logic

Using the logic presented in my previous post to reason through an access control decision based on the above SELinux constraints requires we have a way to evaluate expressions using the operators from the constraint language. I’ll address them in the order they’re presented above:

  1. eq: equality
  2. Testing the equality of two sensitivity levels is straightforward. Using the slev operator we get the sensitivity of a principle and then compare the two using a simple comparison of the strings from our partial ordering. If our reference monitor is optimized it may map the strings to integers (as is the case with SELinux) for a faster comparison but the principle holds.

  3. dom: dominance
  4. This operator is well developed by Chin and Older in their le_{s} operator and was the subject of my previous post.

  5. domby: variation on dominance
  6. This is simply the reverse of the dominance rule and I think it’s included as syntactic sugar.

  7. incomp: incomparable
  8. This operator is only valid when considering the category component of an MLS label and is deferred for future discussion of the Multi-Category Security (MCS) policy.

Now that the operators are sorted out we can use the constraint in an access control decision. I’m using short hand just to keep this post from turning into a book so the logicians among your may groan a bit …
First we must state the partial ordering for secrecy lables in our system. These should be familiar by now:

<br /> Unclassified le_{s} Secret le_{s} Top Secret<br />

Next we define a subject and an object in our system and assign them both secrecy levels:

<br /> slev (O) == Unclassified \<br /> slev (S) == Secret<br />

Now that we’ve defined an Unclassified object and a Secret subject we can revisit the simple security property and the additional rules from the SELinux MLS constraint. I’m going to make up some functions and operators out of thin air so brace yourselves:

<br /> (slev_{l}(S) le_{s} slev _{l}(O_{l})) cup \<br /> (type (S) == mlsfilereadtoclr) cap \<br /> (slev_{h}(S) le_{s} slev_{l}(O)) cup \<br /> (type (S) == mlsreadfile) cup \<br /> (type (O) == mlstrustedobject) supset read<br />

First I’ve augmented the slev function such that it can deal with principles having a high and low sensitivity level. I’ve done so by adding a subscript of ‘l’ for the low sensitivity and an ‘h’ for the high sensitivity.

Second I’ve added another function similar to slev called type. Like slev it allows us to access a component of the security label for a principle. Instead of the classification however it returns the type component of the SELinux label. For the sake of completeness lets give our subject and object types:

<br /> type (S) == type_a \<br /> type (O) == type_b<br />

Now to it’s just a matter of putting it all together. First from the type and sensitivity assignments for our subject ‘S’ and object ‘O’ we can replace instances of slev and type. I’ve only defined one sensitivity label for each object so both low and high labels are the same.

<br /> ((Secret le_{s} Unclassified) cup \<br /> ((type_a == mlsfilereadtoclr) cap \<br /> (Secret le_{s} Unclassified)) cup \<br /> (type_a == mlsreadfile) cup \<br /> (type_b == mlstrustedobject) supset read<br />

Since neither neither subject or object we’re considering have the types listed in this constraint we can quickly mark those comparisons as failing. Further we can simplify terms that have become ‘false’ and we get:

<br /> ((Secret le_{s} Unclassified) supset read<br />

In this simple case we’ve reduced the constraint to the simple security property. Further using the partial ordering we’ve defined we can see that Secret dominates Unclassified and our read request should be allowed by the reference monitor.


This very brief exercise shows the application of a relatively new logical framework to the analysis of a specific SELinux MLS constraint. I’ve found this type of reasoning extremely useful in debugging MLS policy as the available tools (audittoallow) provide no useful information about denials caused by constraints. The exercise performed in this post is equally applicable to any other MLS constraint from the reference policy so if you’re interested give it a try with the constraint for common write operations on files and prove the ★-property.

Up next is the MCS policy …


1 Chad Hanson, SELinux and MLS: Putting the Pieces Together, TCS