MokSec - The Security Framework
thomasg
thomas at gstaedtner.net
Mon Jul 14 17:16:59 CEST 2008
On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <kalle.happonen at iki.fi>
wrote:
> 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.
>
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.
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
> firewall, those don't allow distinguishing of interface.
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
software, so that is imho not that a big deal.
> >
> > 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?
> >
> >
> > 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
> 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
> kernel support for it already.
> > 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).
> 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
> either locally or via a "magic sms".
> > 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.
> 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, and one can add the
> option of remotely disabling access to it. That is very much security,
> way more than phones usually have nowadays, even more than
> laptops/desktops, but not too much to make it hard/annoying to use.
> > Well, that's only a part of a possible security framework, but this
> > are only some thoughts.
> >
> >
> > In addition to that, I'd say all linux security administration best
> > practices should be at least considered, including automatic security
> > updates.
> >
> >
> > 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).
> >
> The fact that it has package management doesn't mean much in itself. I
> think current linux distributions have a pretty good model. A separate
> security updates repo, which just releases security patches, and since
> these are an security update of the recommended version, they don't
> (well shouldn't) break anything, so they can even be pretty safely
> applied automatically. Again, defaults matter. If you need to log in,
> run opkg update; opkg upgrade I bet that most of the phones never get
> patched.
>
> Cheers,
> Kalle
> >
> > 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! :)
> >
> >
> > Possibly to be implemented in a (modular) "security-daemon", as
> > mentioned before.
> >
> > Cheers,
> > Kalle
> >
> > Yorick Moko wrote:
> > > 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 at lists.openmoko.org <mailto:community at lists.openmoko.org>
> > > http://lists.openmoko.org/mailman/listinfo/community
> > >
> >
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org <mailto:community at lists.openmoko.org>
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080714/1d4fa2fa/attachment.htm
More information about the community
mailing list
