[OLPC Security] Application bundles and delegation

[xuan wu]

> This is certainly possible. The alternative is to not allow users to
> change permissions after a program is installed. Do you think that
> this would be a better approach?
That's fine with me, but maybe a system with no "root" control can be
strange to somebody.

> > 2. >As a final note, programs cryptographically signed by OLPC or the
> >    > individual countries may bypass the permission request limits,
> > and request
> >    > any permissions they wish at installation time.
> > This guarantees too much power and responsibility to OLPC which I
> > find unnecessary.  The other programs just have their own rights to
> > announce the access limits to their own files, which means all the
> > programs are all fair, and when one program use another program, it
> > needs permission, just like the real user use the programs. The
> > user may have the right of execute all files, but some programs
> > which are not supposed to be executed directly by the user can just
> > put a "non-executable by John" sign to itself.
>
> I'm sorry; I do not understand the problem here. Could you give a
> specific example?
Tens of thousands of applications may have millions of rules of
permission request to announce. For example, the application App1 needs
the "execution" permission to App2, App3, and App4. how can a single
organization or some organizations maintain these rules and keep them up
to date is out of my imagination. What's more important, the
organizations have to make sure that the rules have the fewest security
problems as possible, as the sets of rules can be seen as a complex
program itself. The idea is, how about let the individual application
maintain the permission of other applications to its files? For example,
App2 has "execution" permission for App1, and App2 only maintain the
permission rules relative to its files. The attempt to make some of the
applications "super" is just to make more security leaks.

> >
> > Another thing in the spec, the "first boot" part.
> > 1. The identity information is centralized, and the server may
> > cause insecurity, as there are always some ways to hack into it.
>
> Yes, but what is the alternative?
With the p2p network, there's no need for the database, as the group
who use the laptops who know each other and have chances to see each
other from time to time can be the identity database itself.

>
> > 2. With only the photo, SN and id,  how can we find the thief or
> > dis function the machine after the a boy lost his laptop, who
> > possibly has  no idea whom to report to except telling his own
> > friends?
>
> The students who have the laptop are students, so they have teachers.
> They need the laptop for school. They report the theft to their school.
Yes, that can be done, through some report system and responsible people,
but wouldn't it be more efficient that the group who use the laptops can
help to solve the problem?

> > How about this? At the first time, the child input his name. Then
> > every time the laptop is turned on ever since, it automatically use
> > the real name to log into the p2p net as long as there's another
> > laptop in a range of, say, 1km. In this net, everyone else  can see
> > who's online, even if no one's in the Internet. Then the thief
> > takes risks everywhere as long as there might be someone else using
> > XO in this range, because that one may know the name that logged
> > in, and may know that he has lost his XO.
>
>
> The goal of the anti-theft system is not to recover laptops. The goal
> is to disable stolen laptops to act as a deterrent.
Actually I didn't find how to disfunction the laptop after it's lost
from the spec, and won't it be better to have the ability to recover the
laptop or trace the man who steal it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/security/attachments/20070211/902b4919/attachment.html