MokSec - The Security Framework
Kalle Happonen
kalle.happonen at iki.fi
Mon Jul 14 18:19:37 CEST 2008
thomasg wrote:
> On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <kalle.happonen at iki.fi
> <mailto: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
I forgive you :)
> 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.
>
That would make sense yes. And since it's a pretty complex device, a
first-run setup is almost needed anyway.
>
> 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.
>
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
if possible, I'd still go for a firewall.
>
>
> >
> > 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>
> <mailto: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>
> <mailto: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 <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
