This mail was posted on the devel list

(http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html).

Thought it would interest a lot of people who are not subscribed to

that list:
Hi Guys,
a few months ago we have planned to improve the security of our beloved

Neo, after we have read about desires of the community regarding to the

security issue.
And here we are. Today I will present you our project MokSec.
What is MokSec?

===============
MokSec is framework which target is to improve the security of the mobile

devices which are based on OpenMoko (and other frameworks which are running on

Neos)
What is our main focus at the moment?

=====================================
The main focus is the encryption over GSM. This is very complicated issue and

for this we searching developer which are willing to work with us on this

interesting project.
What are the other components?

==============================
At the moment we only working on a phone firewall, which will be

blocking/accepting incoming calls. Later one we will add other projects or

developer will be able to add their projects.
Were you can find more informations?

====================================
http://moksec.networld.to                         : The main page

http://moko.networld.to                           : The git repositories

http://networld.to/mailman/listinfo/moksec-public : The mailinglist
We hope that a lot of people will work with us on the security issue.
Happy programming
Alex Oberhauser
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

Hello,

I've only had my freerunner for a week or so, so I'm not too into the

security aspects yet. One thing I did notice was of course passwordless

root login. Now over usb this can be acceptable, but if this is possible

over wifi (I haven't actually tested), it needs the firewall / make it

listen only to the usb.
In addition to that, a separate encrypted partition for /root (or /home

if the account will changed to a non-privileged user) could be nice, but

maybe too heavy and battery draining?
In addition to that, I'd say all linux security administration best

practices should be at least considered, including automatic security

updates.
After the basic security is in good shape, one could move on to fun

things like phone lock/unlock/shutdown with an sms, personal data

backups / remote removal... the possibilities! :)
Cheers,

Kalle
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

Set your own root password.  Fixed.
;

--

Jay Vaughan
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

------=_Part_41696_17956429.1216022615259

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
There's no need for a firewall at all (in fact it's probably the worst

idea).

Just set a root password (you're probably a win user, the command is simply

"passwd") and it'll be fine.
Imho it's not needed to encrypt the whole system.

Would be the better choice to have some crypto-containers for the files that

really need to be secured (phonebook, messages, important documents). We had

some discussion in IRC a while ago and my idea would be to have that

containers and a daemon in background who handles encryption/decryption,

asks for passwords if needed and makes sure that applications who want

access to a encrypted container get it (e.g. dialer wants to look up a

number in the phonebook).

This way the containers can stay decrypted while the phone is on and access

is granted dynamically (as needed).

Yeah, it's a little much effort, but there is no security without it.

If you'd encrypt the whole rootfs you'd have it decrypted the whole time the

phone is on (otherwise nothing would work), what means, the security is

gone.

Well, that's only a part of a possible security framework, but this are only
It's a standard linux system with a lightweight, but still standard, packet

management, so that's how it already is handeled (well, without the

automatic, but I don't like automatic updating anyway).
Possibly to be implemented in a (modular) "security-daemon", as mentioned

before.
------=_Part_41696_17956429.1216022615259

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
<div><span class="gmail_quote">On 7/14/08, <b class="gmail_sendername">Kalle Happonen</b> &lt;<a href="mailto:kalle.happonen@iki.fi">kalle.happonen@iki.fi</a>&gt; wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px...
[ message continues ]

What an insult! *slap* :P. No I'm not a windows user. and I can set the

root password on my device, but defaults matter. And they matter a lot

if openmoko will become more mass-market. A firewall migth be a bit

heavy, I agree, every watt and cycle should try to be saved, but making

dropbear just listen to the usb interface would be a pretty good

compromise, if that is possible.
However, later on an easily configurable firewall would be almost

essential imho. Connecting to the phone (any port) over the wifi should

(almost?)never be allowed as default. Even if the point with the phone

is that users can do what they want, it doesn't mean that the apps they

install shouldn't be protected. And a firewall is almost the only viable

way. There's no easy way of making all the apps listen to just one

interface, and while host.allow/deny is more lightweight than a

No, not the whole system. But well the user homedir would be basically

what we want to protect, and if it was on it's own partition, there is

I think completely dynamic decryption would be too cumbersone to use. If

you mean that it would need an unlock for every received sms (to get the

contact behind the number) and phone call, it's just unfeasible. If you

want to protect the en/decryption key, it needs a passphrase that is

long enough to be of any benefit. The other option is a PKI enabled SIM,

which would be cool. Hence it should be unlocked only once, at bootup.

The sim pin could also be saved on the encrypted partition (maybe the

pin itself again encrypted with the passphrase, so it's not accessible

easily at runtime) so that the user only needs to authenticate once to

use the phone. There could be then options to forget the encryption key

No it doesn't. Everything NEEDS to be decrypted automagically when the

phone is on. Otherwise it's just unusable. The whole system shouldn't be

encrypted, that's just waste.  But having a personal area decrypted at

startup means that only you can access it at bootup, ...
[ message continues ]

------=_Part_44208_1441308.1216048619735

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <kalle.happonen@iki.fi>
Ok, sorry, that was a too mean joke :P

The situation with no root password set is of course not bearable, but I'm

pretty sure that this issue will be solved in a consumer-ready release.

What I'd imagine would be a kind of "first-run-guide", that "forces" (or

allows, however you want :) ) the user to do all the important settings at

the first run of the phone (could be used for backup purposes, too, e.g.

load an xml-file with the settings).

Would make the life way easier for newbies.
A firewall is always a more or less big piece of software, always not the

best for performance, and always a security risk (if it's not dedicated). It

also is not possible to do a easy and _good_ configuration, so however it's

done, it's always suboptimal.

There are not too much services running, and all of them are open source
------=_Part_44208_1441308.1216048619735

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen &lt;<a href="mailto:kalle.happonen@iki.fi">kalle.happonen@iki.fi</a>&gt; wrote:<br><div class="gmail_quote"><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

What an insult! *slap* :P. No I&#39;m not a windows user. and I can set the<br>

root password on my device, but defaults matter. And they matter a lot<br>

if openmoko will become more mass-market. A firewall migth be a bit<br>

heavy, I agree, every watt and cycle should try to be saved, but making<br>

dropbear just listen to the usb interface would be a pretty good<br>

compromise, if that is possible.<br>

</blockqu...
[ message continues ]

That would make sense yes. And since it's a pretty complex device, a

iptables fits into a small kernel, that's not big software :). It might

have some performance hits, but with these traffic amounts it shouldn't

matter. The big but is of course the frontend to it. And open source

software isn't immune to vulnerabilities :). Security patches help, but 
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

SELinux comes to mind. Or at least the capabilites framework.

This way i could choose to allow a app to open sockets. (Little bit like

java sandboxes)

As far as i know we could even have a popup asking for permission.
And to give my 2 Eurocents to the everything as root discusion.

Running user apps as root must end, better soon.

If apps need things only root can do (not much comes to my mind) we

could use sudo wrapper or SELinux rules.
--

Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.

Please print this mail only on recycled paper.
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

what exactly speaks against creating a regular user? did anyone try it

already?

and where exactly is "root" as default user stored?
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

------=_Part_44227_12803238.1216048743301

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
In /etc/passwd :)

Of course you can create another user, as you are used to on any unix

system.

It just doesn't ship with one because the distro comes in ready-to-deploy

images, not with a installer like the binary-distro-people are used to.
------=_Part_44227_12803238.1216048743301

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 5:08 PM, arne anka &lt;<a href="mailto:openmoko@ginguppin.de">openmoko@ginguppin.de</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">&gt; And to give my 2 Eurocents to the everything as root discusion.<br>

&gt; Running user apps as root must end, better soon.<br>

<br>

</div>what exactly speaks against creating a regular user? did anyone try it<br>

already?<br>

and where exactly is &quot;root&quot; as default user stored?</blockquote><div><br>In /etc/passwd :)<br>Of course you can create another user, as you are used to on any unix system.<br>It just doesn&#39;t ship with one because the distro comes in ready-to-deploy images, not with a installer like the binary-distro-people are used to.<br>

</div></div><br>
------=_Part_44227_12803238.1216048743301--

sure? i think it possible that some things won't work when non-root ...
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

------=_Part_44349_3088033.1216049238369

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
Of course some things won't work - if they would, there would be no need for

a special root account.

Basically all the tools someone would use without a terminal should work

(dialer, contacs, ...) no matter what stack is used.

The daemons that need root access run in background and can be controlled by

userspace-programs without root-access.
If of course would take a loginmanager or similar to use a user with

password at startup, because currently the user root is automatically logged

in. Should be easy to "fix".
------=_Part_44349_3088033.1216049238369

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 5:22 PM, arne anka &lt;<a href="mailto:openmoko@ginguppin.de">openmoko@ginguppin.de</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">&gt; Of course you can create another user, as you are used to on any unix<br>

&gt; system.<br>

&gt; It just doesn&#39;t ship with one because the distro comes in ready-to-deploy<br>

&gt; images, not with a installer like the binary-distro-people are used to.<br>

<br>

</div>sure? i think it possible that some things won&#39;t work when non-root ...</blockquote><div><br>Of course some things won&#39;t work - if they would, there would be no need for a special root account.<br>Basically all the tools someone would use without a terminal should work (dialer, contacs, ...) no matter what stack is used.<br>

The daemons that need root access run in background and can be controlled by userspace-programs without root-access.<br><br>If of course woul...
[ message continues ]

Even running only critical things as root, and most stuff on a

no-password unprivileged account would be better. But an user account

with a password a would of course be better. The I'd say that the PIN

could almost be saved somewhere, to avoid the need for a double log-in.
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

------=_Part_45616_13229138.1216052324550

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <kalle.happonen@iki.fi>
I had some thoughts about that, too.

Would be cool if it wasn't necessary to have a PIN at all - you enter the

PIN in the "first-run-wizard", that will store it.

After that you only have one password (of your choise) that does all - the

security daemon would lookup in a key/password-database and use your

password for all things, like decrypting the other containers (phonebook,

messages, e.g.), authing you on the network with the stored pin, unlocking

the phone screen, .....
------=_Part_45616_13229138.1216052324550

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: 7bit

Content-Disposition: inline
On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen &lt;<a href="mailto:kalle.happonen@iki.fi">kalle.happonen@iki.fi</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">thomasg wrote:<br>

&gt; On Mon, Jul 14, 2008 at 5:22 PM, arne anka &lt;<a href="mailto:openmoko@ginguppin.de">openmoko@ginguppin.de</a><br>

</div><div><div></div><div class="Wj3C7c">&gt; &lt;mailto:<a href="mailto:openmoko@ginguppin.de">openmoko@ginguppin.de</a>&gt;&gt; wrote:<br>

&gt;<br>

&gt; &nbsp; &nbsp; &gt; Of course you can create another user, as you are used to on any<br>

&gt; &nbsp; &nbsp; unix<br>

&gt; &nbsp; &nbsp; &gt; system.<br>

&gt; &nbsp; &nbsp; &gt; It just doesn&#39;t ship with one because the distro comes in<br>

&gt; &nbsp; &nbsp; ready-to-deploy<br>

&gt; &nbsp; &a...
[ message continues ]

This is a multi-part message in MIME format.
------_=_NextPart_001_01C8E5D1.2D21B632

Content-Type: text/plain;

	charset="US-ASCII"

Content-Transfer-Encoding: quoted-printable
=20

There's apps that do this, like kdewallet.=20

=20

I was thinking of a picture pin entry.  You display a small set of

pictures with lots of detail, user must tap 1 or more points on each

pictures.=20

=20

Quick entry, good number of bits of encryption, easy to remeber.

=20

Plus, when the phone comes up with a picture, to anybody else it just

looks like it's stuck booting or broken.
________________________________
From: community-bounces@lists.openmoko.org

[mailto:community-bounces@lists.openmoko.org] On Behalf Of thomasg

Sent: Monday, July 14, 2008 12:19 PM

To: List for Openmoko community discussion

Subject: Re: MokSec - The Security Framework
On Mon, Jul 14, 2008 at 6:13 PM, Kalle Happonen <kalle.happonen@iki.fi>

wrote:
=09

	I had some thoughts about that, too.

	Would be cool if it wasn't necessary to have a PIN at all - you

enter the PIN in the "first-run-wizard", that will store it.

	After that you only have one password (of your choise) that does

all - the security daemon would lookup in a key/password-database and

use your password for all things, like decrypting the other containers

(phonebook, messages, e.g.), authing you on the network with the stored

pin, unlocking the phone screen, .....

=09
------_=_NextPart_001_01C8E5D1.2D21B632

Content-Type: text/html;

	charset="US-ASCII"

Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META http-equiv=3DContent-Type content=3D"text/html; =

charset=3Dus-ascii">

<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR></HEAD>

<BODY>

<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20

size=3D2></FONT>&nbsp;</DIV>

<DIV dir=3Dltr align=3Dleft><SPAN class=3D234...
[ message continues ]

I would think on a phone the primary concern is protecting the user

data.  
E.g. sms, contacts, history. 
If somebody was able to malicously install software on the phone, your

pretty much already $%@#'ed.  Not letting it call out helps, but it's

already defeated.  I'm assuming we're not installing a lot of new

unknowns on a secure device, and anything trying to make network

connections is evol. 
I've been picturing running an encrypted rootfs image off an SD card.

There could be multiple encrypted rootfs images, only one would be the

real one, or they all could be used for different reasons.
Once the system boots it's up to the user to unlock the keys to the

encrypted image to be used and that gets booted from the already running

kernel. 
-----Original Message-----

From: community-bounces@lists.openmoko.org

[mailto:community-bounces@lists.openmoko.org] On Behalf Of Tilman

Baumann

Sent: Monday, July 14, 2008 10:38 AM

To: List for Openmoko community discussion

Subject: Re: MokSec - The Security Framework
SELinux comes to mind. Or at least the capabilites framework.

This way i could choose to allow a app to open sockets. (Little bit like
java sandboxes)

As far as i know we could even have a popup asking for permission.
And to give my 2 Eurocents to the everything as root discusion.

Running user apps as root must end, better soon.

If apps need things only root can do (not much comes to my mind) we

could use sudo wrapper or SELinux rules.
--

Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.

Please print this mail only on recycled paper.
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

Apologies for the tardiness of this post.
You're forgetting a large attack vector: social engineering. It doesn't

require someone being able to maliciously install something for it to

get on your system, especially once Moko repositories start to flourish

and organizations setup their own for specific apps/purposes.
Additionally, having used several mobile phones (Smart and otherwise)

often it is helpful to be able to decide what abilities a piece of

downloaded software will have (e.g. a game doesn't need to look at my

address book).
You're also assuming that it's a "secure device" and that the owner will

know how to keep it that way. From experience, I can tell you that as

soon as non-geeks get a hold of this phone (Presumably sometime this
Not a bad idea. I had to do something similar with my Zaurus 5500

several years ago because 14M of storage is not enough. However with the

FreeRunner, I do actually want to keep my rootfs on the rootfs and use
Then what happens if you leave the system in sleep mode and accidentally

leave it somewhere and it "wanders off"? You've unlocked the rootfs

already, so as long as the attacker doesn't reboot the phone, they've

got access.
-KW
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

--------------enig2FC638DFBAFC51EE13648E4F

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
Hi,

this is perhaps not directly in the scope of your project but perhaps it

inspires someones else: A spam filter for SMS. :)
Regards

Robert
--------------enig2FC638DFBAFC51EE13648E4F

Content-Type: application/pgp-signature; name="signature.asc"

Content-Description: OpenPGP digital signature

Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIefxVG9cfwmwwEtoRCExqAJ9o5zy6C4rmGWeJUsaUIFWRXJ3XVgCdGQKm

ZXSqOY6TgJ0NhcUjvA54rMw=

=CSvo

-----END PGP SIGNATURE-----
--------------enig2FC638DFBAFC51EE13648E4F--

It would be more important to not run everything as root I think
_______________________________________________

Openmoko community mailing list

community@lists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community