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
exercise.
* 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 'fbi.gov' 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.
-Cheers
-Matt H.
On Mar 8, 2007, at 10:04 PM, dwight at supercomputer.org 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:
http://yro.slashdot.org/article.pl?sid=06/12/02/0415209
http://yro.slashdot.org/article.pl?sid=06/12/04/0456220
-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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
To: Paul Lambert <[EMAIL PROTECTED]>
Cc: SVHMPC <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> wrote:
The four contact 2.5mm connectors seem pretty common and have a
variety of
stereo/mic headsets available.
Paul
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:svhmpc-
[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/
svhmpc_telefono.revejo.org
_______________________________________________
SVHMPC mailing list
[EMAIL PROTECTED]
http://telefono.revejo.org/mailman/listinfo/svhmpc_telefono.revejo.org
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
