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

[Albert Cahalan]

Adric,
It may be 'trivial' to kill all processes started by a given user, but
it's not obvious to me that this solves the problem Marcus raised, for
two reasons, one specific and one general.
Specifically, it's fairly clear from the needs of software like Browse
and Etoys that 'activity instances' are not in one-to-one correspondence
with processes or even process-groups. This means that you may not know
which uid to kill off in order to close a given activity instance and
that one uid may be hosting several unrelated activities.

By "unrelated activities" do you mean that multiple instances
of Browse will share the same UID? If so, that needs fixing.
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.

More generally, activity instances can communicate with one another
through four basic mechanisms (and probably a few side-channels).
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.

Second, instances of differing types can communicate, with user consent,
through the datastore and the clipboard, and without user consent
through DBus, through X, and perhaps over the network.

datastore: user consent, so no serious worry
clipboard: user consent, so no serious worry
DBus: needs to be blocked
X: note the new SE Linux stuff for X
network: activities must request this at install time

All of these kinds of communication create unknown levels of risk of
cross-instance contamination. The ones involving the datastore may
persist across reboots. Finally, each suggests the possibility of
running privilege-escalation attacks against system and session
components that I am hard-pressed to mitigate on any reasonable
timeframe.

For gen2, make sure the CPU supports the NX bit.

If at all affordable, get a 64-bit address space.
This makes address space randomization far more effective.

Similarly, discussion of spamming is hopefully mitigated by the
default network rate limiting and cpu usage limiting of the platform.

Depends on whether you're able to specify workable limits and on the
rate at which exploits are developed for the activities that are endowed
with network access. (or for the underlying system as a whole).

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.

Here's a potential weakness that concerns me: how rapidly can we
actually deploy a security patch to, say, avahi or the presence service?

Fortunately avahi seems to have a solid containment design.

[Albert Cahalan]

Similarly, discussion of spamming is hopefully mitigated by the
default network rate limiting and cpu usage limiting of the platform.
If you see weakness in this plan that are not already discussed,
please share. Or submit patches :)

Network rate limiting likely requires kernel patches that need lots
of deep thought before implementing.

Right. It's a good thing somebody did that years ago. :-)
(not that I think this is a critical thing to limit)

Use the iptables command. Match on UID. You have a number of choices
here. The ones that look interesting are:

--limit --limit-burst --quota --set-dscp --set-dscp-class
--set-mark --set-tos --mark --length --hashlimit --dscp
--dscp-class --connlimit-above --connlimit-mask --connbytes
--connbytes-dir --connbytes-mode

If that isn't enough for you, the tc command offers some
extra stuff. Mark the packets with iptables, and then use
the tc command to act on that.

It happens that absolute CPU usage limiting is something that I've
recently been playing with in patches

Why? It's a single-user machine. A better idea would be to go the
other way. SCHED_FIFO and SCHED_RR are useful for many things.
(computer-in-the-loop performance audio, general data collection
for experiments, soft modems, etc.)

The jack audio developers have a kernel module that lets realtime
features be made available based on GID. A simpler solution is to
just comment out the security check. I'd probably give 1/3 of the
realtime levels to activites that desire it at install time, and
an extra 1/3 to the olpc user.

I think it's useful in discussions to distinguish between what the
BitFrost spec says, and what is actually
implemented. A specification does not code make. So, when I make
observations about the
*current* state of affairs, it's with full recognition that a
fully-implemented BitFrost would take
care of the issue. But BitFrost *isn't* fully implemented, and some
of it will be a real slog
to get working.

My default assumption when talking about such matters is that we
are discussing the things that are likely to be implemented when
serious deployment is well under way. That's when the system
first becomes interesting for malware writers.

[Michael Stone]

Albert,

Since you seem to have deeper familiarity with the iptables stuff than I
do, would you be willing to contribute a patch on top of Marcus'
permissions work [1] that implements a basic on/off switch for IP-based
network access?

Also, regarding SCHED_FIFO and SCHED_RR: do I correctly understand you
to be saying that it's straightforward to use one of those schedulers to
guarantee system responsiveness in the face of a misbehaving activity?

Thanks,

Michael

[1]: http://dev.laptop.org/git?p=users/mleech/security;a=shortlog;h=permissions;

Post by Albert Cahalan

Network rate limiting likely requires kernel patches that need lots
of deep thought before implementing.

Right. It's a good thing somebody did that years ago. :-)
(not that I think this is a critical thing to limit)
Use the iptables command. Match on UID. You have a number of choices
--limit --limit-burst --quota --set-dscp --set-dscp-class
--set-mark --set-tos --mark --length --hashlimit --dscp
--dscp-class --connlimit-above --connlimit-mask --connbytes
--connbytes-dir --connbytes-mode
If that isn't enough for you, the tc command offers some
extra stuff. Mark the packets with iptables, and then use
the tc command to act on that.

It happens that absolute CPU usage limiting is something that I've
recently been playing with in patches

Why? It's a single-user machine. A better idea would be to go the
other way. SCHED_FIFO and SCHED_RR are useful for many things.
(computer-in-the-loop performance audio, general data collection
for experiments, soft modems, etc.)
The jack audio developers have a kernel module that lets realtime
features be made available based on GID. A simpler solution is to
just comment out the security check. I'd probably give 1/3 of the
realtime levels to activites that desire it at install time, and
an extra 1/3 to the olpc user.

[Albert Cahalan]

Post by Michael Stone
Since you seem to have deeper familiarity with the iptables stuff than I
do, would you be willing to contribute a patch on top of Marcus'
permissions work [1] that implements a basic on/off switch for IP-based
network access?

I'm happy to help, although my time is spread thin and
that's a pile of python code. I could write a shell script
for you. If you wish, you could translate from bash to python.
Would that be much help?

I'm thinking that the script might take a UID number as the
first argument. Maybe there would be two scripts, for turning
on and turing off. It may be better to have the script take a
list of UIDs to block, or a list of UIDs to allow, with all the
old state getting replaced.

Post by Michael Stone
Also, regarding SCHED_FIFO and SCHED_RR: do I correctly understand you
to be saying that it's straightforward to use one of those schedulers to
guarantee system responsiveness in the face of a misbehaving activity?

No.

You could in fact do that. You'd need to run all other
code with one of those, probably SCHED_RR with the
lowest priority.

I was suggesting just the opposite though. Step back
and take a look at the situation we have. If a process
misbehaves severely, the user will hit the power button.
They will then NOT run that program again. This is OK.
It's very simple. There are no limits or UI issues to
bother with.

It is strongly desireable to let activities hog the CPU.
This allows activities to do reliable low-latency audio,
reliable experiment control, reliable radio modems, etc.
Thus the restriction of SCHED_FIFO and SCHED_RR
to root should be relaxed, as is done for many of the
Linux distributions that are meant for musicians.

[Michael Stone]

Post by Albert Cahalan

Post by Michael Stone
Since you seem to have deeper familiarity with the iptables stuff than I
do, would you be willing to contribute a patch on top of Marcus'
permissions work [1] that implements a basic on/off switch for IP-based
network access?

I'm happy to help, although my time is spread thin and
that's a pile of python code. I could write a shell script
for you. If you wish, you could translate from bash to python.
Would that be much help?

That would be great.

Post by Albert Cahalan
I'm thinking that the script might take a UID number as the
first argument. Maybe there would be two scripts, for turning
on and turing off. It may be better to have the script take a
list of UIDs to block, or a list of UIDs to allow, with all the
old state getting replaced.

I'm amenable to completely resetting the firewall state each time we
want to change it.

Post by Albert Cahalan
I was suggesting just the opposite though. Step back
and take a look at the situation we have. If a process
misbehaves severely, the user will hit the power button.
They will then NOT run that program again. This is OK.
It's very simple. There are no limits or UI issues to
bother with.
It is strongly desireable to let activities hog the CPU.
This allows activities to do reliable low-latency audio,
reliable experiment control, reliable radio modems, etc.
Thus the restriction of SCHED_FIFO and SCHED_RR
to root should be relaxed, as is done for many of the
Linux distributions that are meant for musicians.

Ah, okay. Hmm. I don't currently know enough about the scheduler
subsystem to really evaluate the merit of your suggestion, but I will
certainly consider it as the need arises.

Anyway, thanks for your suggestions and for your assistance with the
first piece of the network isolation feature.

Michael

[Carl-Daniel Hailfinger]

Post by Albert Cahalan

Similarly, discussion of spamming is hopefully mitigated by the
default network rate limiting and cpu usage limiting of the platform.
If you see weakness in this plan that are not already discussed,
please share. Or submit patches :)

Network rate limiting likely requires kernel patches that need lots
of deep thought before implementing.

Right. It's a good thing somebody did that years ago. :-)
(not that I think this is a critical thing to limit)
Use the iptables command. Match on UID. You have a number of choices

AFAIK Netfilter UID matching has been deprecated and/or removed from
mainline kernels.

Regards,
Carl-Daniel

[Albert Cahalan]

On Dec 3, 2007 10:58 PM, Carl-Daniel Hailfinger

Post by Carl-Daniel Hailfinger

Post by Albert Cahalan

Network rate limiting likely requires kernel patches that need lots
of deep thought before implementing.

Right. It's a good thing somebody did that years ago. :-)
(not that I think this is a critical thing to limit)
Use the iptables command. Match on UID. You have a number of choices

AFAIK Netfilter UID matching has been deprecated and/or removed from
mainline kernels.

If so, that's horrible. Mind sending the patches to restore it?
Distinct EUID and RUID would be nice, along with support
for filtering on the incoming side.

Meanwhile, OLPC is using a kernel that can be configured
to support UID matching. That'll do for now.

We can also solve the problem with SE Linux. I guess this
means that the kernel doesn't get an version change until
the Bitfrost stuff converted to SE Linux.

[Michael Stone]

Post by Albert Cahalan
By "unrelated activities" do you mean that multiple instances
of Browse will share the same UID? If so, that needs fixing.

The difficulty is that forcing activity instances into a 1-1
correspondence with uids exacerbates our current problems with memory
usage and activity launch time. Otherwise, I'm fine with the idea.

Post by Albert Cahalan
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.

Post by Albert Cahalan

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'.

Post by Albert Cahalan
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.

Post by Albert Cahalan
X: note the new SE Linux stuff for X

I assume you're referring to XACE here?

Post by Albert Cahalan
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.

Post by Albert Cahalan
Fortunately avahi seems to have a solid containment design.

Very true. Unfortunately, much of our software does not... yet. :)

Michael

[Albert Cahalan]

Post by Michael Stone

Post by Albert Cahalan
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.

Post by Michael Stone

Post by Albert Cahalan

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.

Post by Michael Stone

Post by Albert Cahalan
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.

Post by Michael Stone

Post by Albert Cahalan
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

Post by Michael Stone

Post by Albert Cahalan
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)

Post by Michael Stone

Post by Albert Cahalan
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.