MokSec - The Security Framework
Kalle Happonen
kalle.happonen at iki.fi
Mon Jul 14 15:35:07 CEST 2008
thomasg wrote:
> On 7/14/08, *Kalle Happonen* <kalle.happonen at iki.fi
> <mailto:kalle.happonen at iki.fi>> wrote:
>
> 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.
>
>
> 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.
>
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
firewall, those don't allow distinguishing of interface.
>
> 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
>
More information about the community
mailing list
