[OLPC Security] Please read the spec and the discussion first, thanks.

[Albert Cahalan]

On Dec 1, 2007 5:49 PM, Michael Stone <michael at laptop.org> wrote:
> On Sat, Dec 01, 2007 at 01:48:02AM -0500, Albert Cahalan wrote:

>> In the long term, throw-away SE Linux security info might be
>> better than throw-away UIDs. It's a bit more powerful, and it
>> will ultimately be more compatible and thus more acceptable.
>
> Please explain further, at your convenience.

I'll start with XACE-SELINUX. This is the way desktop
security is going. You can take advantage of that instead
of writing your own stuff.

SE Linux is mandatory security rather than discretionary
security. Besides keeping insider spies in check, this is
great for preventing accidents. It deals well with buggy stuff
written by incompetant fools, like the guys who wrote a
printer driver installer which made OpenOffice setuid root.

The supposedly multi-user workstation can not be having
UID values be random. It ruins accountability. For the big
corporate and educational environments, it ruins central
user account management. This is where you ultimately
need to go though, in multiple ways and for multiple reasons.
First of all, simply having sugar as a log-in option would
be wonderful. A school using desktop computers could
default to sugar, while still keeping network-wide UID
allocation and keeping GNOME for the older kids. Second
of all, you need to share code with the traditional desktop
and it would be really good for the traditional desktop to
gain the ability to sandbox things like sugar does. There
is no way this will work with the UID being used.

>>> First, instances of the same activity-type can communicate directly
>>> through their shared 'data' dir.
>>
>> This is one of the more troublesome problems. It does effect "only"
>> the one activity. The browser is quite a lot unfortunately.
>> Avoiding usage of shared data would be good. Second best would be
>> to treat the shared data as being both hostile and volatile.
>
> I argued strongly that activity configuration files are properly stored
> in the datastore along with every other piece of user-generated data.
>
> People who believe that Sugar should be able to run mostly-unported
> software argued that they needed a persistent unix file-system on which
> to store their data. Hence the current semantics of 'data'.

Both are right. :-)

It's like full-screen. You want all apps to be that way,
but you need to support the others as well.

When authors avoid the shared writable data, you can
give them gold stars.

>> datastore: user consent, so no serious worry
>
> First, access to configuration files does not require user consent.
> Second, today, neither Sugar nor the DataStore perform access checks.
> (See #2328 and #3801). Changing this is one of my higher priorities.

Well, you know about the problem and intend to fix it,
so I'm not going to worry. I'll start to worry if 123456 kids
get laptops before the problem is fixed.

>> X: note the new SE Linux stuff for X
>
> I assume you're referring to XACE here?

Not plain XACE, but XACE-SELINUX.
http://lists.laptop.org/pipermail/devel/2007-November/008032.html

>> Network rate limiting probably belongs in the school server.
>> This would ensure that each student gets a fair share of the
>> internet connection, no matter how many programs they run.
>
> Hmm. Curious thought.

Be sure to use a policy on the school server which
will set the ECN bit. This avoids wasted bandwidth
from dropping packets. I think the RED scheduler
can do this. ("man tc" for how to set up RED)

>> Fortunately avahi seems to have a solid containment design.
>
> Very true. Unfortunately, much of our software does not... yet. :)

If you still worry, note that Fedora has an SE Linux policy
to contain avahi even more. If I recall right, SE Linux is not
currently installed on the XO.

BTW, I'm nearly certain that SE Linux can restrict clock changes.