Matt Waxes Poetic About Software Security [Was: Re: [SVHMPC] Headset connector query]

Matthew S. Hamrick mhamrick at
Fri Mar 9 20:17:27 CET 2007

Well... ya' know... the first step might be to not include software  
that turns the AV inputs on remotely.

But the real problems are:
a) can you device be upgraded remotely without your knowledge. and
b) can your software be exploited remotely without your knowledge.

With respect to the former, the content czars of Hollywood have been  
insisting that as part of DRM systems, device manufacturers build  
systems that can be forcibly remotely upgraded. The idea being that  
when the encryption algorithm or keys for a particular application  
are circumvented, a new system can be forced on the device owner  
without their consent. Or rather, in their view, device owners  
consent to this treatment as a condition of receiving license to play  
big-4 content on their devices. Just another example of how the music  
biz is, in Hunter S. Thompson's words, "The music business is a cruel  
and shallow money trench, a long plastic hallway where thieves and  
pimps run free, and good men die like dogs. There's also a negative  
side. " One of the great joys of this project is that we don't have  
to deal with these people.

With respect to the latter, you're never going to be able to have an  
"ultimately secure" device, of course. And the most secure computers  
are those that aren't connected to net, don't have monitors and don't  
have microphones. Then there's the much ballyhooed tradeoff between  
usability and security. In software security circles, there's been a  
little bit of debate as to whether this tradeoff really exists or if  
it's simply a myth propagated by lazy software engineers who don't  
want to "do the right thing" with respect to security. Matt Bishop,  
considered to be one of the shining lights of reason in an otherwise  
murky swamp of computer security disinformation, edited a book  
recently titled "Security and Usability," which is a collection of  
essays about the subject. Early in life I adopted a philosophy of  
"everything you know is true." Put another way, it's fun to think  
about how the world would have to change to make even nonsensical  
statements true. If you're a Robert Anton Wilson fan, then you know  
that the answer is generally "not much."  This is simply a roundabout  
way of saying... making secure systems is hard; getting software  
engineers to "do the right thing" with respect to security is also  
hard (though generally not because software engineers are lazy);  
making usable systems is hard; and making usable, secure systems is  
goddamn'd near impossible.

But a good start might be to build systems that had security designed  
into them. Gary McGraw has a book called "Designing Security In" or  
something like that. It's a bit rambling, but not a bad read. The  
argument goes something like this...

* Systems that don't have security "designed in" will not allow  
software engineers to express security concerns.
* Once software is written and released, it has to be supported.
* Retroactively adding security features to a codebase is a costly  
* Releasing security patches is a costly exercise.
* If you look at the DCF (Discounted Cash Flow) of the costs of  
"doing it right" up front versus the cost of security redesign and  
patches, you wind up spending less in present value terms by doing it  
right the first time.

The counter-argument has always been that this model does not take  
opportunity costs into account. Like everyone else in the world, I  
like to bitch about Window's security behavior. But the M$ guys  
would, I'm pretty sure, say that getting software out to the market  
"quickly" was some part of their success and that had they paused to  
consider the security implications of what they were doing, they  
wouldn't be the dominant player they are today.

And the sad truth is... they're right.

Microsoft, as an organization, was not designed to consider security.  
So my big complaint isn't that Windows has generally had pretty  
crappy security behaviors, it's that Microsoft did not value security  
and did not modify their organization to encourage the development of  
secure or trusted software.

But before I start sounding like a Unix partisan, let me cast a few  
stones toward that glass house. Unix has a well deserved reputation  
as being the most secure operating system from the early 1970's; with  
the possible exception of TOPS-20, VMS (okay... late 70's) or VM/SP.  
In other words, it's not that secure, people! A whole generation of  
security researchers has come and gone since the Unix security model  
was invented. OSes like Flask/Flux, QNX and the various microkernels  
like L4 have introduced cool new models.

But the problem has generally been that in order to get a platform  
people will use, it's generally considered important to make it easy  
for people to port software to that new platform. In the Unix  
community, this generally means slavish devotion to Posix. (Okay...  
if you're going to have slavish devotion to something, Posix isn't  
the worst thing in the world to be slavishly devoted to.)

But the POSIX security model is based on the whole concept of "user  
security." That is, the most important thing a system can do is keep  
one user's files safe from another user. That's great, but how well  
does this work on a TuxPhone? Not especially well is the answer.  
Mobile devices are generally assigned to one individual... one user.  
Does this mean that you don't need security? No... we need security  
for exactly the purpose that Dwight is bringing up. In reality,  
modern devices have thousands of users because the software that goes  
into them come from at least a thousand different developers. Any one  
of them could, if they're really clever, introduce a vulnerability  
into the system and later sell an exploit to organized crime or  
corrupt governments.

Open Source advocates (like myself) will sometimes echo Eric  
Raymond's assertion that "given enough eyeballs, all bugs are  
shallow." While I agree with the sentiment, I don't agree that there  
are nearly enough eyeballs doing security code reviews. And it's also  
very difficult to defend against vulnerabilities that spring from  
"unusual" component interactions.

One thing that we can do to help make software more secure and more  
trusted is to build systems that grok new security concepts. SE/Linux  
is heading in the right direction, but it's clearly an effort  
intended for server use. I've thought long and hard about how to  
administer a mobile device running SE/Linux and I've got to say, I  
believe it would take a staff of three sysadmins to properly  
administer one SE/Linux phone. Umbrella was also a good start, but  
the project is more or less moribund, and I don't feel comfortable  
using a system that isn't maintained. PalmSource's Access Linux  
Platform had some advanced security features added, but they didn't  
go nearly far enough, and developed tools that are a royal pain in  
the ass to administer and don't have the expressibility required to  
protect much of anything.

What I've been working on lately is a simple system to add "code  
origin" as a parameter in an access control decision. If you think of  
the current Unix security model, you can use chmod() to tell the  
system whether a particular permission (like read, write or execute)  
for a particular object (like a file) should be granted to a  
particular subject (like a user or group.) ACLs (Access Control  
Lists) essentially do the same thing, but are a bit more flexible  
with respect to how you can grant permissions to multiple users or  
groups. Now imagine that if there was a way to identify the origin of  
a code component, you could make an access control decision based on  
the origin of the code.

This is essentially what Microsoft, Symbian, et al do with their code  
signing infrastructures. In theory, a "trusted" developer goes out  
and writes some code, then gets it signed by a key certified by  
VeriSign, and then IE or the WinCE executive verifies the signature  
before allowing it to be executed. This is required, but not  
sufficient. What I'm talking about is granting fine-grained access  
control permissions to code components based on their origin.

You could then make a ACL for /dev/audio that says, "only code signed  
by me, Harald Welte and the gStreamer team should be able to access  
this resource."

Then extending the model, you could use the per-process firewalling  
features in modern kernels to specify things like, "code from  
Microsoft or any domain ending in '.ng' or '' don't get to  
make outbound network connections."

But I like the idea of a switch for the microphone and a cover for  
the camera, too.

-Matt H.

On Mar 8, 2007, at 10:04 PM, dwight at wrote:

> While I've mentioned this to some people already, here's just  
> another reminder
> to make certain to design your microphone right. You don't want to  
> just hook
> up the mic to the lines straight from the Telit chip. You need to make
> certain that there's an independent switch to turn off the mic, and  
> which
> makes certain that it stays off. The same thing applies to the camera.
> Otherwise, you open yourself up to others activating the mic remotely.
> As has already been documented per these articles:
>      -dwight-
> On Thursday 08 March 2007 07:35, adrian cockcroft wrote:
>> The case design I'm working on has a PCB that fills the case and the
>> back splits just above the PCB so its easy to have
>> mic/headphone/microUSB plugs mounted on the phone PCB and cutout from
>> the split point. I'm not sure about the gumstix GSM module, we may
>> need to stretch the case a bit to make that fit.
>> Adrian
>> On 3/8/07, thomas.cooksey at <thomas.cooksey at> wrote:
>>> Sorry, but I really think there should be no jack on the PCB at all.
>>> Instead, I think all the signals should be broken out with a  
>>> standard
>>> pitch set of pins. I'm thinking of the type of connectors used  
>>> for the
>>> power button, HDD led etc inside PC cases. That way people can  
>>> easily
>>> change the jack to whatever they want. You could also supply a  
>>> standard
>>> "pigtail" for a headset of your choice. The other advantage is  
>>> that the
>>> jack(s) can be screwed into the case easily, without having to  
>>> design
>>> the case around the PCB to get the connector close enough to the  
>>> side of
>>> the case.
>>> Cheers,
>>> Tom
>>> -----Original Message-----
>>> From: svhmpc-bounces at
>>> [mailto:svhmpc-bounces at] On Behalf Of Craig  
>>> Hughes
>>> Sent: 08 March 2007 04:09
>>> To: Benjamin C Burns
>>> Cc: SVHMPC; Mike Cheponis; Paul Lambert
>>> Subject: Re: [SVHMPC] Headset connector query
>>> Yeah, we'll have BT support too -- but some folks prefer wired  
>>> headsets.
>>> C
>>> On Mar 7, 2007, at 6:14 PM, Benjamin C Burns wrote:
>>>> This probably isn't the best way to go about it, but I just  
>>>> decided to
>>>> require a bluetooth headset.  Of course, this will only work if the
>>>> Gumstix supports bluetooth headsets, but I'm not overly concerned
>>>> about
>>>> it right now because I'm way behind for my school deadline and
>>>> whatever
>>>> doesn't work at this point isn't going to work until sometime down
>>>> the road.
>>>> I do have a 1/8" stereo headphone jack w/ jack sense, though.
>>>> This probably wasn't too helpful though...  Sorry?
>>>> Ben
>>>> Mike Cheponis wrote:
>>>>> The actual "standard" is a 3-contact 2.5 mm connector.  This is to
>>>>> allow headsets to be plugged in.
>>>>> However, in order to play music in stereo, the Palm smartphones
>>>>> have an adaptor that converts the 2.5 mm 3-conductor into a
>>>>> standard 3.5 mm stereo headphone connector.  I don't know what
>>>>> sort of clever electronics must be inside the Treo to do this, but
>>>>> I find it doesn't always work reliably, and also requires an
>>>>> external honkin' adaptor.
>>>>> My suggestion?  Put on a dedicated 3.5 mm jack for stereo
>>>>> headphones, and put on a three-conductor 2.5 mm jack for standard
>>>>> headset use; That is, put on two connectors.
>>>>> As for the 2.5 mm connector, I have no issue if it's a 4-conductor
>>>>> type, as long as standard 3-conductor headsets can plug in.  (and,
>>>>> frankly, bluetooth headsets still suck, and a wired headset is so
>>>>> much nicer.  Maybe with the higher-speed BT we can squeeze CD-
>>>>> quality sound to our headphones.  But, still, wired headsets and/
>>>>> or headphones don't need batteries...)
>>>>> -Mike
>>>>> On Wed, 7 Mar 2007, adrian cockcroft wrote:
>>>>>> Date: Wed, 7 Mar 2007 17:34:10 -0800
>>>>>> From: adrian cockcroft <adrian.cockcroft at>
>>>>>> To: Paul Lambert <Paul at>
>>>>>> Cc: SVHMPC <SVHMPC at>
>>>>>> Subject: Re: [SVHMPC] Headset connector query
>>>>>> Thats what the OpenMoko site says too, they are compatible  
>>>>>> with some
>>>>>> specific Motorola models, so 4 contact 2.5mm seems standard  
>>>>>> enough.
>>>>>> Adrian
>>>>>> On 3/7/07, Paul Lambert <Paul at> wrote:
>>>>>>> The four contact 2.5mm connectors seem pretty common and have a
>>>>>>> variety of
>>>>>>> stereo/mic headsets available.
>>>>>>> Paul
>>>>>>>> -----Original Message-----
>>>>>>>> From: svhmpc-bounces at [mailto:svhmpc-
>>>>>>>> bounces at] On Behalf Of Craig Hughes
>>>>>>>> Sent: Wednesday, March 07, 2007 5:18 PM
>>>>>>>> To: SVHMPC
>>>>>>>> Subject: [SVHMPC] Headset connector query
>>>>>>>> So, we're looking at how to allow connection of an external
>>>>>>>> headset/
>>>>>>>> mic to the gumstix cellphone board thing.  We could stick  
>>>>>>>> with the
>>>>>>>> standard 3.5mm jack thing we have now, but there aren't many
>>>>>>>> actual
>>>>>>>> cellphone headsets which use those connector, and the
>>>>>>>> connectors are
>>>>>>>> somewhat large.  There are about as many headset connectors on
>>>>>>>> real-
>>>>>>>> world cellphones as there are cellphones, and they all appear
>>>>>>>> to be
>>>>>>>> completely undocumented.
>>>>>>>> So: Does anyone have thoughts on the best interface/ 
>>>>>>>> connector to
>>>>>>>> populate onto the gumstix cellstix board?  We could say  
>>>>>>>> something
>>>>>>>> like "Headset-compatible with the nokia 9237" or whatever  
>>>>>>>> and just
>>>>>>>> let people get their own favorite compatible headset (but we'd
>>>>>>>> need
>>>>>>>> to know the schematic for the nokia 9237 headset connector  
>>>>>>>> in that
>>>>>>>> case), or just stick with the 3.5mm jacks we have now...
>>>>>>>> C
>>>>>>>> _______________________________________________
>>>>>>>> SVHMPC mailing list
>>>>>>>> SVHMPC at
>>>>>>> _______________________________________________
>>>>>>> SVHMPC mailing list
>>>>>>> SVHMPC at
>>>>>> _______________________________________________
>>>>>> SVHMPC mailing list
>>>>>> SVHMPC at
>>>>> _______________________________________________
>>>>> SVHMPC mailing list
>>>>> SVHMPC at
>>>> _______________________________________________
>>>> SVHMPC mailing list
>>>> SVHMPC at
>>> _______________________________________________
>>> SVHMPC mailing list
>>> SVHMPC at
>>> _______________________________________________
>>> SVHMPC mailing list
>>> SVHMPC at
>> _______________________________________________
>> SVHMPC mailing list
>> SVHMPC at
> _______________________________________________
> SVHMPC mailing list

More information about the community mailing list