On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <<a href="mailto:kalle.happonen@iki.fi">kalle.happonen@iki.fi</a>> wrote:<br><div class="gmail_quote"><div> </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'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>
</blockquote><div> <br>Ok, sorry, that was a too mean joke :P<br>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.<br>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).<br>
Would make the life way easier for newbies.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, later on an easily configurable firewall would be almost<br>
essential imho. Connecting to the phone (any port) over the wifi should<br>
(almost?)never be allowed as default. Even if the point with the phone<br>
is that users can do what they want, it doesn't mean that the apps they<br>
install shouldn't be protected. And a firewall is almost the only viable<br>
way. There's no easy way of making all the apps listen to just one<br>
interface, and while host.allow/deny is more lightweight than a<br>
firewall, those don't allow distinguishing of interface.</blockquote><div> <br>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.<br>
There are not too much services running, and all of them are open source software, so that is imho not that a big deal.<br><br>
</div><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"><br>
><br>
> In addition to that, a separate encrypted partition for /root (or<br>
> /home<br>
> if the account will changed to a non-privileged user) could be<br>
> nice, but<br>
> maybe too heavy and battery draining?<br>
><br>
><br>
> Imho it's not needed to encrypt the whole system.<br>
> Would be the better choice to have some crypto-containers for the<br>
> files that really need to be secured (phonebook, messages, important<br>
> documents). We had some discussion in IRC a while ago and my idea would<br>
</div>No, not the whole system. But well the user homedir would be basically<br>
what we want to protect, and if it was on it's own partition, there is<br>
kernel support for it already.<br>
<div class="Ih2E3d">> be to have that containers and a daemon in background who handles<br>
> encryption/decryption, asks for passwords if needed and makes sure<br>
> that applications who want access to a encrypted container get it<br>
> (e.g. dialer wants to look up a number in the phonebook).<br>
> This way the containers can stay decrypted while the phone is on and<br>
> access is granted dynamically (as needed).<br>
</div>I think completely dynamic decryption would be too cumbersone to use. If<br>
you mean that it would need an unlock for every received sms (to get the<br>
contact behind the number) and phone call, it's just unfeasible. If you<br>
want to protect the en/decryption key, it needs a passphrase that is<br>
long enough to be of any benefit. The other option is a PKI enabled SIM,<br>
which would be cool. Hence it should be unlocked only once, at bootup.<br>
The sim pin could also be saved on the encrypted partition (maybe the<br>
pin itself again encrypted with the passphrase, so it's not accessible<br>
easily at runtime) so that the user only needs to authenticate once to<br>
use the phone. There could be then options to forget the encryption key<br>
either locally or via a "magic sms".<br>
<div class="Ih2E3d">> Yeah, it's a little much effort, but there is no security without it.<br>
> If you'd encrypt the whole rootfs you'd have it decrypted the whole<br>
> time the phone is on (otherwise nothing would work), what means, the<br>
> security is gone.<br>
</div>No it doesn't. Everything NEEDS to be decrypted automagically when the<br>
phone is on. Otherwise it's just unusable. The whole system shouldn't be<br>
encrypted, that's just waste. But having a personal area decrypted at<br>
startup means that only you can access it at bootup, and one can add the<br>
option of remotely disabling access to it. That is very much security,<br>
way more than phones usually have nowadays, even more than<br>
laptops/desktops, but not too much to make it hard/annoying to use.<br>
<div class="Ih2E3d">> Well, that's only a part of a possible security framework, but this<br>
> are only some thoughts.<br>
><br>
><br>
> In addition to that, I'd say all linux security administration best<br>
> practices should be at least considered, including automatic security<br>
> updates.<br>
><br>
><br>
> It's a standard linux system with a lightweight, but still standard,<br>
> packet management, so that's how it already is handeled (well, without<br>
> the automatic, but I don't like automatic updating anyway).<br>
><br>
</div>The fact that it has package management doesn't mean much in itself. I<br>
think current linux distributions have a pretty good model. A separate<br>
security updates repo, which just releases security patches, and since<br>
these are an security update of the recommended version, they don't<br>
(well shouldn't) break anything, so they can even be pretty safely<br>
applied automatically. Again, defaults matter. If you need to log in,<br>
run opkg update; opkg upgrade I bet that most of the phones never get<br>
patched.<br>
<br>
Cheers,<br>
Kalle<br>
<div><div></div><div class="Wj3C7c">><br>
> After the basic security is in good shape, one could move on to fun<br>
> things like phone lock/unlock/shutdown with an sms, personal data<br>
> backups / remote removal... the possibilities! :)<br>
><br>
><br>
> Possibly to be implemented in a (modular) "security-daemon", as<br>
> mentioned before.<br>
><br>
> Cheers,<br>
> Kalle<br>
><br>
> Yorick Moko wrote:<br>
> > This mail was posted on the devel list<br>
> ><br>
> (<a href="http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html" target="_blank">http://lists.openmoko.org/pipermail/openmoko-devel/2008-July/003594.html</a>).<br>
> > Thought it would interest a lot of people who are not subscribed to<br>
> > that list:<br>
> ><br>
> ><br>
> > Hi Guys,<br>
> ><br>
> > a few months ago we have planned to improve the security of our<br>
> beloved<br>
> > Neo, after we have read about desires of the community regarding<br>
> to the<br>
> > security issue.<br>
> ><br>
> > And here we are. Today I will present you our project MokSec.<br>
> ><br>
> > What is MokSec?<br>
> > ===============<br>
> ><br>
> > MokSec is framework which target is to improve the security of<br>
> the mobile<br>
> > devices which are based on OpenMoko (and other frameworks which<br>
> are running on<br>
> > Neos)<br>
> ><br>
> > What is our main focus at the moment?<br>
> > =====================================<br>
> ><br>
> > The main focus is the encryption over GSM. This is very<br>
> complicated issue and<br>
> > for this we searching developer which are willing to work with<br>
> us on this<br>
> > interesting project.<br>
> ><br>
> > What are the other components?<br>
> > ==============================<br>
> ><br>
> > At the moment we only working on a phone firewall, which will be<br>
> > blocking/accepting incoming calls. Later one we will add other<br>
> projects or<br>
> > developer will be able to add their projects.<br>
> ><br>
> > Were you can find more informations?<br>
> > ====================================<br>
> ><br>
> > <a href="http://moksec.networld.to" target="_blank">http://moksec.networld.to</a> : The main page<br>
> > <a href="http://moko.networld.to" target="_blank">http://moko.networld.to</a> : The git<br>
> repositories<br>
> > <a href="http://networld.to/mailman/listinfo/moksec-public" target="_blank">http://networld.to/mailman/listinfo/moksec-public</a> : The mailinglist<br>
> ><br>
> > We hope that a lot of people will work with us on the security<br>
> issue.<br>
> ><br>
> > Happy programming<br>
> ><br>
> > Alex Oberhauser<br>
> ><br>
> > _______________________________________________<br>
> > Openmoko community mailing list<br>
</div></div>> > <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a> <mailto:<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a>><br>
<div class="Ih2E3d">> > <a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> Openmoko community mailing list<br>
</div>> <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a> <mailto:<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a>><br>
<div><div></div><div class="Wj3C7c">> <a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Openmoko community mailing list<br>
> <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
> <a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Openmoko community mailing list<br>
<a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>
<a href="http://lists.openmoko.org/mailman/listinfo/community" target="_blank">http://lists.openmoko.org/mailman/listinfo/community</a><br>
</div></div></blockquote></div><br>