login
Search
------=_Part_44208_1441308.1216048619735
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inlineOn Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen
wrote:> What an insult! *slap* :P. No I'm not a windows user. and I can set the
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
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.
> >
------=_Part_44208_1441308.1216048619735
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Mon, Jul 14, 2008 at 3:35 PM, Kalle Happonen <kalle.happonen@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.
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.
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".
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.
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
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
------=_Part_44208_1441308.1216048619735--
| Peter Zijlstra | [RFC][PATCH 7/7] lockdep: spin_lock_nest_lock() |
| Gabriel C | Re: 2.6.24-rc2-mm1 |
| Andrew Morton | Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP |
| Jiri Kosina | Re: 2.6.21-rc5-mm4 |
git: | |
| Gregory Haskins | [RFC PATCH 00/17] virtual-bus |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
