[OLPC Security] Terminals

[Albert Cahalan]

One of our present security difficulties is that the Terminal activity
is not isolated. It is de-isolated so that it can serve the dual role of
root terminal and 'general exploration' terminal. Perhaps reviving the
Quake Terminal for the root-terminal role and isolating the Terminal
activity proper would be a nice way to solve half of our security issue?

No.

First of all, that would force usage of the root account to get
to the olpc account. There is little reason to want a random
user, but plenty of reason to want both olpc and root.

Second of all, the ability to de-isolate an arbitrary activity
is important. Isolation needs to be under the user's control.
Except to prevent a user from locking himself out by isolating
the de-isolation tool, no activity should be specially known
to Bitfrost or Sugar. Isolation is righfully a user choice.
It's OK to make isolation easier though, to avoid accidents.

[Jameson "Chema" Quinn]

2008/8/1 Eben Eliason <eben.eliason at gmail.com>

Why does it matter that you cannot adjust the screen brightness from
the console using the special keys? You can adjust it from Sugar
without root access. The idea was to understand what limits we'd face
using the console for root access instead of a special terminal
activity. What are the Sugar/X Window actions that require root
access?

"It doesn't matter if you have to abandon Sugar to do system
administration or to recover from a problem?" Walter, I'm shocked; I
would've expected you to be arguing on the other side: "Sugar should
be the preferred environment." That we shouldn't be kicking people
out of Sugar, particularly when their system is fragile and in need of
diagnosis, repair, or upgrade. We should keep them in the environment
they know and understand, where the Frame works, the controls work,
the tabs work the same way, the keyboard keys all do the same things.
It was hard for the Support Gang to explain to people how to become
root so they could diagnose or fix something they reported as a
problem (like a full filesystem, a USB key that didn't work, ...).
OLPC was also changing the way you become root (su versus sudo) in
different software releases, based on Fedora changes. We hashed all
this out in January, and the Terminal got a new "#" button at the top,
which injects the right command to make you root. There's no such
button in the console. If we push people back to the console, the
support load increases. It's easier to get them to run the Terminal
applic...uh, activity, and press the root button, and type this
command. Also, in Terminal, cut and paste works to send us back
diagnostic results via Browse.
The owners of free software based machines also need the ability to
inspect and revise the free software in those machines -- or it isn't
free as in freedom. Legally, OLPC can push that ability out to the
very corners of the system (e.g. "You can't do that in Sugar."). But
morally and philosophically, we ought to be pulling it right into the
heart of the system ("Of course you can, and it's so easy; here, let
me show you!").

I agree with everything said above.

Let's not lose sight of what's going on here. The whole reason we are
having this discussion at all is because of OLPC's "security" model
(Bitfrost). If the security model doesn't permit integrated,
interactive root access that lets people diagnose, repair,
investigate, and alter their systems, there's something wrong with the
security model -- not something wrong with root access.

And I wonder if it could really be so simple. Is it possible that we could
simply have a P_ROOT permission as well, or does that blow Bitfrost out of
the water? In a way I'd hope not, since the whole point is that the desire
for root is requested/advertised, and therefore can (eventually) be denied;
P_ROOT clearly wouldn't be granted within the default permissions either,
once we have them.

Coincidentally, I have a patch which does just that! See my thread on sugar at ...
OK, I guess I should copy it to devel@ and security@ while I'm at it.

I write this assuming that this might not help matters at all...it could be

too lenient. But perhaps we could offer the P_ROOT only to activities which
a) request it and b) are signed by some signing authority (could be us,
could be a country, etc.), where the security section of the control panel
offers a place to designate trusted signing authorities. I'm no security
guru, though, which I willingly admit! Is anything I've mentioned worth
even considering?

Once we have activity signatures, we can talk about this more concretely. I
expect that, for general bitfrost permissions, there will be a bitfrost
control panel that allows you to grant certain permissions to a specific
(hashed version of an) activity; or to delegate the power to grant certain
permissions to other signers (such as the author of an activity, so that
updates get same permissions). I think that it is reasonable to put
additional restrictions on the P_ROOT permission: perhaps it can ONLY be
granted to activities installed at build time OR signed by current XO?
(Then, to change the version of your terminal, you'd either have to do a
full update to a new build, or touch the new version of terminal activity
with Develop to "make it yours").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080801/6028a712/attachment.htm

[Michael Stone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| Is it possible that we could
| simply have a P_ROOT permission as well, or does that blow Bitfrost out of
| the water?

1. According to my reading of

http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l442

Bitfrost is not compatible with a P_ROOT permission.

2. Direct manipulations of the trusted code base by the distribution
chain are also supported:

http://dev.laptop.org/git?p=users/mstone/security;a=blob;f=bitfrost.txt;h=96f4997602d817abf7be90a00bf68b3a79a73005;hb=HEAD#l450

3. I believe that the existing 'olpc-update', 'yum+gpg', and
'olpc-configure+rpms' mechanisms already satisfy the demands of (2).

We need an _interface_ that allows users to specify which Activities can run
with which permissions.

Correct.

To build that, we need Rainbow to support different running different
Activities with different permissions.

Rainbow has supported placing activities into different groups based on
the contents of a 'permissions.info' file for months. See commit
58c164f2 which shipped in rainbow-0.7.11 on March 25, 2008. (The work
leading up to that commit was actually available in commit bd26557f from
November 13, 2007 but was not merged until March because of various
"code freezes" that lasted somewhat longer than they should.)

As you can see, the present security difficulties stem from the lack of
effort spent on recording user intentions about what permissions should
be applied to what activities. Signatures do absolutely nothing to
address this problem -- they only permit an as-yet undesigned system
interpreter to check whether the authors W of claim X about blob Y knew
secret Z. These assertions yield no new power because the Bitfrost
security model asserts that trusting that author W wrote blob Y implies
no trust in blob Y itself. It's a good reason to display hints about
blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author
W, but it is _NOT_ sufficient to grant Y permissions in the initial
default-deny configuration proposed by Bitfrost.

It is probably appropriate, here, to reiterate my third claim above --
namely, that deployment-team's desire to add code directly to the TCB is
_already covered_ by other mechanisms unrelated to activity installation.

To build that, we need Activities to be identified by a unique secure
token. To build that, we need a new bundle format.

No new bundle format is needed to track activities according to
non-spoofable tokens. All that is needed is to teach the software making
authorization decisions (Sugar) to use the correct token.

Regards,

Michael

[Jameson &quot;Chema&quot; Quinn]

Post by Michael Stone
As you can see, the present security difficulties stem from the lack of
effort spent on recording user intentions about what permissions should
be applied to what activities. Signatures do absolutely nothing to
address this problem -- they only permit an as-yet undesigned system
interpreter to check whether the authors W of claim X about blob Y knew
secret Z.

This is literally true, of course, but I think that it is a misunderstanding
of what Benjamin said. The "signatures" stumbling block is actually the
"hashes" stumbling block - that is, the ability to refer to blob Y in a way
that is stable across installation/repacking, .pyc compilation, etc, but
secure against changes.

Post by Michael Stone
These assertions yield no new power because the Bitfrost
security model asserts that trusting that author W wrote blob Y implies
no trust in blob Y itself. It's a good reason to display hints about
blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author
W, but it is _NOT_ sufficient to grant Y permissions in the initial
default-deny configuration proposed by Bitfrost.

This is also close to true, but not entirely. In general, we will not trust
code simply because it comes from a given author. However, Bitfrost is not
quite as categorical as you imply. I think that the code/user distinction is
primarily a *distinction* between trust in a user and trust in their code,
not a firm declaration that the latter is impossible without explicit
intervention. Here's the relevant paragraph:

*"Unfortunately, software received through a friend or acquaintance is
completely untrusted code, because there's no trust mapping between people
and software: trusting a friend isn't, and cannot be, the same as trusting
code coming from that friend. The friend's machine might be taken over, and
may be attempting to send malicious code to all her friends, or the friend
might be trying to execute a prank, or he might have written?either out of
ignorance or malice -- software that is sometimes malicious."*

Post by Michael Stone
No new bundle format is needed to track activities according to
non-spoofable tokens. All that is needed is to teach the software making
authorization decisions (Sugar) to use the correct token.

I disagree - for stronger security, a new bundle format which includes
hashes is, if not 100% necessary, at least clearly desirable. However, you
are right that we can do much better without this, and I am currently
working on a patch which does that - for 5657.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080802/9cb381ae/attachment.htm

[Michael Stone]

Post by Jameson &quot;Chema&quot; Quinn

Post by Michael Stone
As you can see, the present security difficulties stem from the lack of
effort spent on recording user intentions about what permissions should
be applied to what activities. Signatures do absolutely nothing to
address this problem -- they only permit an as-yet undesigned system
interpreter to check whether the authors W of claim X about blob Y knew
secret Z.

This is literally true, of course, but I think that it is a misunderstanding
of what Benjamin said. The "signatures" stumbling block is actually the
"hashes" stumbling block - that is, the ability to refer to blob Y in a way
that is stable across installation/repacking, .pyc compilation, etc, but
secure against changes.

1) Hashing is unnecessary. The raw contents of the activity's directory
on the filesystem are the best identification of that activity.
Naturally, hashing such as is provided by olpc-contents can be used for
efficiency purposes; however, this hashing (really manifest
construction) can and should be performed directly on the activity's
unpacked files at installation before the activity is run.

Post by Jameson &quot;Chema&quot; Quinn

Post by Michael Stone
These assertions yield no new power because the Bitfrost
security model asserts that trusting that author W wrote blob Y implies
no trust in blob Y itself. It's a good reason to display hints about
blob Y, to display blob Y nearby to blobs Y_1, Y_2, etc. also by author
W, but it is _NOT_ sufficient to grant Y permissions in the initial
default-deny configuration proposed by Bitfrost.

This is also close to true, but not entirely. In general, we will not trust
code simply because it comes from a given author. However, Bitfrost is not
quite as categorical as you imply. I think that the code/user distinction is
primarily a *distinction* between trust in a user and trust in their code,
not a firm declaration that the latter is impossible without explicit
*"Unfortunately, software received through a friend or acquaintance is
completely untrusted code, because there's no trust mapping between people
and software: trusting a friend isn't, and cannot be, the same as trusting
code coming from that friend. The friend's machine might be taken over, and
may be attempting to send malicious code to all her friends, or the friend
might be trying to execute a prank,

And the relevant line is the final one;

"or he might have written?either out of ignorance or malice -- software
that is sometimes malicious."

which clearly considers the potential for "friends" to intentionally
ship you malicious code.

(I'm absolutely willing to grant that better identity mechanisms would
do a world of good to improve the actual security provided by the
system; however, I continue to insist that they are at best tangential
to the fundamental problem which is, as stated above, the lack of a
suitable _user interface_ for recording user-generated permission
grants.)

Post by Jameson &quot;Chema&quot; Quinn

Post by Michael Stone
No new bundle format is needed to track activities according to
non-spoofable tokens. All that is needed is to teach the software making
authorization decisions (Sugar) to use the correct token.

I disagree - for stronger security, a new bundle format which includes
hashes is, if not 100% necessary, at least clearly desirable. However, you
are right that we can do much better without this, and I am currently
working on a patch which does that - for 5657.

As above, hashes can be computed on the unpacked activity bundles. No
modification to the bundle format is necessary; moreover, why would you
ever rely on the correctness of a manifest supplied by the bundle
itself?

[Jameson &quot;Chema&quot; Quinn]

Post by Michael Stone
As above, hashes can be computed on the unpacked activity bundles. No
modification to the bundle format is necessary; moreover, why would you
ever rely on the correctness of a manifest supplied by the bundle
itself?

The current manifest format hashes everything in a directory. That includes
python compiled files (arguably correct, but also arguably a separate
issue); any signatures or subfiles of signatures (manifests and hashes)
which may be included in the future; git-related invisible files which may
be on a developer's machine; and the dist/ directory, likewise. This could
be a problem. A smart bundle format would, I argue, at a minimum exempt
signatures and cryptographic manifest (not MANIFEST, but HASHES) from being
hashed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080802/3e261e20/attachment.htm

[Albert Cahalan]

Look, there is no reason to care about hashes. What is the fear
here, that the jffs2 filesystem will fail? We have pathnames.

Permissions are granted by the user. The only exception is when
the OS is initially installed, or when the whole OS is upgraded.

Permissions are tied to an inode. Since the kernel enforces that
directories may not have hard links, one may also tie permissions
to a directory.

It'd be nice to have a way for activities to specify reasons to
grant various permissions. This isn't a requirement. It'd be nice
to to have a way for activities to specify permissions that are
of no use (and thus should not be offered in the UI). This is not
a requirement.

Signatures and hashes are complexity. Complexity tends to be the
enemy of security. The answer is really simple: every activity,
no matter where it comes from (claiming to be an upgrade or not),
gets sandboxed by default. Users grant permissions as desired.

Bitfrost sure is compatible with P_ROOT. Of course any such
permission would implicitly grant all others; such is life.
There certainly should be a way to specify that setuid is to
be respected, that su should be allowed, that UID should be 0,
that the user's real home directory should be used, or that
various capability bits should be enabled.

The more dangerous items might best be handled via commands
to be run at the Linux console, ensuring that nobody can hit
them with random mouse clicking.