Software security - sad state

Events over the last year have pushed me to investigate software security much closer.

The summary of my thoughts are (somewhat just common sense):

• Developer statements regarding secure coding practices only have real weight if the developers have substantial security training.
• Security is a joke if not part of the initial design.
• Statements from application designers regarding security only have weight if the designer has some security training.
• Systems are at the mercy of their libraries and frameworks.  
• If you use Struts, I think you should be very concerned.
• Libraries and frameworks should be refreshed (or at least reviewed) regularly. 
• It is a bad idea to use extra functionality in libraries "just because you can" versus a realistic need.  I would recommend throw-away prototypes of tools as learning tools instead of high profile production applications.
• Put lots of time into understanding default configurations and any functionality which allows you to disable unneeded functionality. 
• Layers of security are needed.
• Too many people underestimate security needs and don't worry about it unless you end up in the news.  Not being in the news implies that they are doing something right from their perspective - hard to change that. 
• Security is not implement and forget functionality.
• Software companies want to sell you "just one more" layer of security.  Shaped like a silver bullet in worst case.  Other times it indicates it is green product - i.e. much recycled content.
• Security regression tests would be useful.
• Automated security tests, in general, would be a benefit.  Problem is time and resources though. 

I have a few other thoughts I am mulling over;

• The root of many issues is the generalist nature of systems and a hierarchical nature of dependencies. Example:
• Programming frameworks support much more functionality than will be used in individual applications.  Some of that functionality has security implications - such as the ability to launch a new OS process.
• Regarding the previous item, the framework leverages generic functionality in the language runtime to launch a process.
• The  programming language runtime uses OS level support to launch processes.  
• The OS support for launching processes is normally provided in the form of a shared library which provides generic services.
• The shared library services are available to all applications with access to the library.

Restricting access to functionality, such as launching processes, is possible via things such as SELinux but:

1. The complexity is pretty high which also leads to potential errors
2. Harder to provide justification to management for the required time with the ever increasing pace of software development.  
3. This particular solution affects entire servers and most likely many servers.

Other possibilities exist to restrict functionality at the language runtime level (i.e. Java process).  An example of this is implementing a Java Security Manager & appropriate policy.

1. This implies that a large number of activities need to be white listed.  That just isn't reasonable or feasible in some cases due to the amount of code involved and the resources available to maintain the policy.
2. Any change in the environment (i.e. lib or framework version) effectively requires a total security review to prevent inclusion of unused white list entries.

So white listing is difficult because:

1. It is an all or nothing process (i.e. affects an entire server or entire application).  
2. Much of the work is related to 3rd party software (libs and frameworks) for which you would need to figure out the needs from scratch.  

Alternatively, if you are working from a blacklist only standpoint:

1. You may miss items and have unexpected security holes.
2. There are few methods available for blacklisting probably because of issues related to item 1.

If Java flags existed which disabled functionality (process launching), it could be considered a form of blacklisting (functionality).  At the moment, I don't believe any flags like this exist. 

*****
Work in progress.. Rewording some sections needed to clarify the intended thought.  Overall, there has got to be a better way to deal with security (especially in substantially resource constrained shops).

CNC research - initial thoughts and info

I've been itching to build something interesting and useful for some time.  I was looking for something that requires learning some new things outside normal software development skills.  I had decided a while back that a CNC router fits the criteria.

My first steps involved lots of internet searches which returned me to a few common sources of information which led to many others.

• http://www.cnccookbook.com/CCResourcesInd.htm
• http://www.cnczone.com/
• http://www.mmsonline.com/columns/a-few-interesting-cnc-related-websites

I purchased a book, 'The CNC Cookbook' by E Hess, and think it was a pretty good introduction to lots of related items.  All the above resources pointed me to a number of other areas to learn about.

1. Physical motion control
1. Driving
1. Linear rails
2. Lead screw
3. Ball screw
2. Driven
1. Gantry
2. Moving bed X/Y
1. hybrid gantry/moving bed (i.e. bed is X axis, gantry is Y & Z)
1. have to determine if there are any benefits to this
2. Motors
1. Stepper
2. Servo
3. Electronics
1. Motor control
1. H-bridge
2. driver IC's
1. Allegro A4988
2. TI DRV8825
3. Freescale MC34932
4. ST L6480
5. ST L6203, etc
6. Toshiba TB62209FG?
2. Power supply
1. Regulated
2. Unregulated 
3. switched
4. linear
4. Software
1. CAD
2. CAM
3. G-code creation, editing, verification, post-processing
4. controller program
5. Overall system control
1. Microcontrollers
2. PC

Some early decisions I made are

• I don't want to be dependent upon a desktop computer while operating the CNC router.  So any gcode should be feed from either a small system like a Raspberry Pi or maybe include extra memory if needed to contain data for even large jobs.  Have to think further on it.
• I am going to use a Arduino Leonardo for the basic coordination.  This may be somewhat limiting; the GRBL software is not officially supported on it but there is a git hub branch which sounds like folks had reasonable success in using.  I may use the Leonardo in a different capacity.  I could probably borrow my sons Uno which would be supported.  
•  

Trying to evaluate the various driver IC's.  There seems to be very little 3rd party documented comparison/contrasts between driver options.  I'm having to look pretty hard to find discussions about experiences with individual drivers.  Fortunately, that still provides lots of useful info.

1. So far the TI DRV8825 or close relative seems like the best choice.  Received my DRV8825 chip in the mail.  I have not worked with SMD chips before and I think I am better off getting a pre-built break-out board.
2. The ST L6480 is nice but the problem is that it has features which are not appropriate for at least some CNC setups.  The features of issue involve acceleration/deceleration ramping which is somewhat handled internally.  Based on a forum post elsewhere, it sounds like the functionality can be disabled. 
3. The Allegro A4988 is lacking some of the useful features of the DRV8825.
4. Toshiba TB62209FG - I am still researching this one but it may have some of the same "excessive functionality" as the L6480.
5. Freescale MC34932 - still researching.  looks like higher current capacity and maybe more functionality than A4988 so it could be useful in some cases.  I don't think my current needs will go this high though so the DRV8825 is still likely a better choice.
6. ST L6203, etc  - still researching.  looks like less features but more current.  Probably not what I am looking for.

Will continue updating this as ideas/decisions occur.  Need to document features of the driver IC's, etc.

Home built welded sheet metal drawers - beginner learning the hard way

This post is to document the good, bad and ugly aspects of my construction of 3 drawers for my welding cart/table.

I had done a little research early on but didn't find lots of info at the time regarding building welded metal drawers from scratch.  What I did know upfront is that thin sheet metal is challenging to work with.  I also gathered from various sources that high heat input would likely lead to warping.  I had experienced this already when stitching some small rectangular pieces of sheet together or the bottom of the cart.

Anyways, knowing the the following setup was not optimum, I decided to go ahead anyways.  I just wanted a useable result but it need not be overly pretty.  The knowledge gained far outweighed the unattractive welds in this case.

1. .035 gas-less Flux core setup
2. 20 or 22 gauge sheet metal (forgetting which off top of head right now)
3. 1 drawer was made from a single continuous piece of sheet metal which was just cut in places to allow forming.  Forming involved hand bending (as in clamp and push like mad) and hammering over a wood mockup of the final drawer.  The end result is sort of a Christmas package type of look - solid sides and bottom with diagonal welded seams on the ends.  This drawer is the most rigid of the 3 due to the amount of overlapping sheet metal from what I can tell.  The resulting dimensions and tolerances of the drawer were not very close due to the hand bending and hammering required. 
4. The other 2 drawers were made of individual rectangular pieces of sheet which were then welded together.  
1. One drawer was mostly corner welded.  This drawer had the most issues.  I had huge trouble trying to avoid blowing holes in the edges.
2. The other drawer used over-sized pieces which I bent 1-2 inches around corners.  The bending was done by clamping a scrap piece of angle iron to my welding table which the sheet metal between them.  Bending was done by hand and some light hammering.  This drawer was done last and utilized knowledge gained from the previous 2 drawers.  This drawer was the easiest to produce plus it had decent rigidity and dimensions/tolerances that were reasonably close considering the methods I used.

Early lessons

• Doing tack type welds was the most viable way to prevent major warping
• Attempts at continuous welds resulted in just unbearable ugly welds.  Burn through was prevalent - alternating holes and blobs.  The blobs seemed to be a bit cold - more like they adhered to the surface than fused properly to surrounding metal.
• Flux core wire is just plain messy and a real pain to cleanup afterwards. 
• Prepping the areas where welds occur with a wire brush drill attachment helped with weld consistency since some light to medium levels of rust had been forming.  This is much easier to do BEFORE clamping things together.
• A good solid clamping of the pieces helped significantly.  It seems like the overlapping sheet metal had a sort of heat sink effect when well clamped.  When not well clamped, the top level of sheet metal tended to vaporize more or less - leaving holes with fused edges at best.
•  Clamping some scrap bar or angle stock improved things further.  I think this was a combination of the heat sink effect and tighter overlap.
• When welding inside the box, the lower level of light seemed to cause extra problems with the self-darkening helmet. I'm not sure if some extra lighting directed into the box would have helped reduce shadows and allow me to see a little farther along the direction of travel. 
• Sheet metal snips usually resulted in ugly cuts, tired and extremely cramped hands and plenty of sore spots from sharp pointed edges through fairly thick gloves.  
• A cheap Chicago Electric sheet metal shear from Harbor Freight was a huge improvement over the manual snips I have.
• Inside corner welds are especially challenging.  Extra lighting would help even though I was working outside.
• My recent addition of a Hobart magnifying lens in my Harbor Freight helmet did help weld visibility (I think I got a 2 diopter lens). 

What would have provided a more professional result (some low cost ideas while others are $$$).

• A sheet metal & pan brake - I think this would make the biggest difference for several reasons.
• Using bends instead of welds results in less heat distortion; bend as much as possible.
• Proper tooling has a better chance of maintaining correct dimensions.
• An improved design which prevented or reduced inside corner welds would help.  A design where welds occur outside of corners and probably only on the external sides would make for quicker and easier welding. It would be easier to cleanup outside welds as well.
• A reasonable amount of overlapping metal combined with proper joint design and attachment method should increase rigidity a bit.  This is based somewhat on the methods I used and the skills/equipment I had available - it may be wasteful under other circumstances.
• Avoid welds on the the front if at all possible. These just resulted in poor looks and more cleanup.
• Use of TIG and lower amperage or gas MIG + smaller wire ( .023 seems recommended per a few blogs).  These seem like valid suggestions I ran across for reducing heat distortion.
• Use of a good backing plate as heat sink.  I just picked up some aluminum to use in the future.
• Possibly the use of some rivets in place of some welds.  Sometimes simple is better..
• Some yet to be determined way to minimize the hazard of some sharp edges.  Rolling the top edges seems like it would do the job but I would have need to plan that in the beginning.  Not sure what other options might be viable. I'm not very impressed by the results of a light sanding of edges or a light grinding with a Dremel.
• A proper set of jigs to hold things in place would prevent a few problems.

 In the end, I have 3 workable drawers.  One has been mounted and very functional for 6 months or so.  The other 2 I am gathering what I need to mount them to the welding cart/table.  A couple coats of enamel paint goes a long way to improving the overall look of things.

Just want to give a hats off to the professional welders and hobbyist that have gained the skills and patience to work with sheet metal and produce many of the awesome examples out there for viewing over the internet.  It is certainly more than one skill; welding is part of it but component and jig design are a big part of it from what I just went through.

[2014/05/07 Update] Some pics of the before final assembly.

The slides and brackets are upside down for picture taking convenience. I will be welding the angle iron "feet" to the underside of my welding table/cart top. It is a very hefty assembly - I could surly have gone lighter weight with the angle iron which is 1/4" think.  The flat pieces welded to the angle are 1/8" think. I may take some smaller flat bar and weld it between the 2 sides - that should make it easier to keep the spacing close as I try to weld this onto the cart.

Here I am test fitting things.  Remember that the whole thing is upside down from how it will get mounted.  I will rivet the drawers to the slides once I work out the exact spacing.  I mainly need a little space at what will be the top so that I can still clamp the table in the general area of the top drawer.  I also tend to clamp the ground cable to the table top in that area.

I am still debating whether to empty the whole cart and flip it over so I can weld this on or simply try to raise/clamp it in place and weld from below.  Welding from below is *really* not a strong point for me but at the same time the cart weighs much more than I originally intended and some aspects will make flipping it more difficult.  Guess I will figure it out when the time comes.

[update 05/8/2014] I ended up tacking the drawers in place while upright.  A few clamps and a little help got it in place reasonably well.

Here is end result.

 Not perfect but very usable.

Thanks for looking!
Scott

Thermal Arc 211i - beginner issue with some 1lb spools

I'm not sure what the setup is like on other welders but I found one small problem which isn't necessarily the fault of the Thermal Arc but they could probably have mitigated it.

There is a large spring which provides tension to keep the spool from unraveling on its own.  The image below is a snippet out of the manual.

The issue is that some 1lb spools (not sure of the larger ones) snag on the openings in the spool sides. 

Some spools have open areas on the sides of the spool which can catch the spring and will cause clicking and other really annoying feed issues which are time consuming and wasteful to cleanup after.  Below is a picture of 2 spools where one has has solid sides and therefore no issue while the other does have openings and caused feed issues.

The workaround I found is to take a piece of sheet metal (I think 20 gauge is what I used here) and make a small backing plate to place between the spool and spring.  This has eliminated the feed issues I ran into.  There is likely a bit more friction with the plate compared to the solid plastic spool but I don't think it will make a large difference.  The metal plate did make it a little more difficult to mount the spool though - maybe thinner sheet metal would be a little easier.  I'm sure other solutions exist but I would recommend that anyone working with small spools keep something handy in case you can't get your normal brand.

Microcontroller tinkering & Electronic design and simulation

I have been interested in tinkering with microcontrollers and electronics for some time.  You can learn a lot through some trial and error but I would also like a slightly more formal method to help with designs and debugging.

My educational background predates easily accessible electronic design software.  I only worked with digital logic in college but would like to toy with some analog and digital/analog hybrid projects.

I went looking for some open source software which would provide enough functionality but hopefully not be too outrageously hard to understand.  I research some info online and finally decided to give QUCS a try.

I must say that my first thought was that it was going to be impossible to use without some sort of training.  That was based on some quick random attempts at using the software which was the wrong way to go about it.  I am glad I finally had a free minute to sit down and work through some of the examples and help.  I found the examples in the help system useful but it seems like the text could have been a little clearer.  Overall, I am now pretty impressed with the software.

We'll see how well things scale [performance, usability and technically].  Some of the projects I would like to implement and seem feasible include:

• CNC router
• Solar power augmented RC plane or quadcopter
• small robot with features interesting enough for our kids to want to be involved in the project

I'm still researching to see what particular boards may be good candidates for the ideas.  We have an Arduino Uno and it could likely work for the CNC router if combined with the GRBL software and some stepper drivers.  Hard to give up features for simplicity and low cost sometimes.  I really would like to try out the Mach 3 (and eventually 4) software but that pushing into the more capable boards below.

Some other boards might have higher benefits.  I know there are number of other board/shield type combos but these are some initial items I found interesting.

• Arduino Due 
• nice but sounds like it is electrically fragile if you are not extra careful (compared to an Uno).
• Arduino Ire
• TBD
• Teensy 3.1
• Very small; could be a good candidate to support an RC project.
• BeagleBone based system
• This is more like the Raspberry Pi of which we have one; not sure this fits projects I mention in this post.
• Intel Galileo 
• It is nice to have alternatives but I have some reservations about a few things.  I am not an expert by any stretch and look forward to hearing what both users and more knowledgeable folks have to say.
• TI Launchpad
• In my research on this; it seems like the HW is a great deal but you don't get a free fully featured/capable development environment.  Unless I just misread things, the IDE available from TI is limited unless you buy the ~$400-$500 license.  If I were trying to make money by selling products, this makes sense but I can't justify it for the 1 off type things I am thinking about.  If I find a nice idea for post-retirement income someday then maybe but not right now; Arduino based products seem better from a hobby/tinker perspective.

A few other projects of interest if time and money present themselves would be:

• 3D laser scanner
• Direct metal laser sintering machine

Those would take substantial research on top of what I have already done.  I have a feeling that those would fall outside any potential budget I may set.

I have some other higher power items that would be interesting but likely outside my hobby budget and current skills.

Sons limmerick - Ouch

I have pulled a muscle or three.
My mother asked 'How could that be'?
After getting a sprain,
I still felt right as rain,
until I ran into the tree.

The tree was extremely tall,
but I was just having a ball.
The branches went 'creak',
and then I went 'EEK!',
because I had started to fall.

I fell into one of our ditches.
Poison ivy went all up my britches.
After unloading that batch,
I started to scratch.
Somebody make this stop, it itches!

I took one of the neighborhood cats,
away from catching some rats.
I got it to scratch me,
which made me say 'ouchie!',
when I got attacked by the bats.

The bats dropped down busloads of poo.
All that I could do was say 'eww'.
I then ran away,
to where I could stay.
And now I am talking to you.