On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <[EMAIL PROTECTED]> 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@lists.openmoko.org <mailto:community@lists.openmoko.org> > > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > > > > _______________________________________________ > > Openmoko community mailing list > > community@lists.openmoko.org <mailto: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 > > > > > _______________________________________________ > 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