[OLPC Security] SuperUser permission for the Driver??

[Michael Stone]

We have an activity that wants superuser privilege in order to poke
kernel memory.

The real questions we should be attempting to address here include:

* Who is granting privilege to this activity?

* How are they doing so?

* How should we record the decision?

- My tentative answer is that we should store activities with
different security properties in well-known directory chains
with appropriately restricted write access.

* What kinds of abuse are these mechanisms vulnerable to?

* Whose responsibility is it to handle the error condition that the
human operator does not, him-or-herself posess superuser privilege,
e.g. for theft-deterrence reasons?

Comments?

Michael

[Carl-Daniel Hailfinger]

Post by Michael Stone
We have an activity that wants superuser privilege in order to poke
kernel memory.

Hello? Please take the poor activity out back and shoot it. No activity
has any business poking kernel memory.

Post by Michael Stone
* Who is granting privilege to this activity?

Everybody who wants to ridicule the security model.

Post by Michael Stone
* How are they doing so?
* How should we record the decision?
- My tentative answer is that we should store activities with
different security properties in well-known directory chains
with appropriately restricted write access.
* What kinds of abuse are these mechanisms vulnerable to?
* Whose responsibility is it to handle the error condition that the
human operator does not, him-or-herself posess superuser privilege,
e.g. for theft-deterrence reasons?

Just say no.

Having an activity poke kernel memory is a really strong sign that the
interface is totally broken.

Regards,
Carl-Daniel

[Deepak Saxena]

Post by Carl-Daniel Hailfinger

Post by Michael Stone
We have an activity that wants superuser privilege in order to poke
kernel memory.

Hello? Please take the poor activity out back and shoot it. No activity
has any business poking kernel memory.

What if I replace Michael's statement with some specific use cases:

- An activity requires a specific device driver module to be (un)loaded
to properly function and loading this driver requires su privilege.

or:

- An activity requires a device to switch operation modes and that
operation mode is configured via a sysfs file. The file is poked
by a library API, but it requires su privilege to do so.

I agree with Paul that we need to have a solution to these
cases iff we want to support running arbitrary software and
hw combinations on the XO. The other option is to limit the
scope of the system to a very specific set of sw and hw,
treating the XO as embedded education appliance instead of
a general-purpose laptop device, which I don't think
we want to do.

I don't have any immediate answers to any of Michael's questions
but I think looking at how the standard ditros deal with this
would be a starting point.

~Deepak

[Benjamin M. Schwartz]

Deepak Saxena wrote:
| I agree with Paul that we need to have a solution to these
| cases iff we want to support running arbitrary software and
| hw combinations on the XO. The other option is to limit the
| scope of the system to a very specific set of sw and hw,
| treating the XO as embedded education appliance instead of
| a general-purpose laptop device, which I don't think
| we want to do.

That is _precisely_ what I want to do.

OLPC's goal is to distribute XOs to the poorest children in the world.
That means that in the category of electronics, the great majority will
have the XO and nothing else. Peripherals are a rarity, an edge case.

There is a planned design to allow the user to grant extra privileges to
different Activities, but those privileges will probably never extend to
loading arbitrary kernel modules. I have no problem declaring that anyone
who is modifying the kernel is a "developer", and should therefore get a
devkey and call modprobe themselves.

- --Ben

[Jay Sulzberger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| I agree with Paul that we need to have a solution to these
| cases iff we want to support running arbitrary software and
| hw combinations on the XO. The other option is to limit the
| scope of the system to a very specific set of sw and hw,
| treating the XO as embedded education appliance instead of
| a general-purpose laptop device, which I don't think
| we want to do.
That is _precisely_ what I want to do.
OLPC's goal is to distribute XOs to the poorest children in the world.
That means that in the category of electronics, the great majority will
have the XO and nothing else. Peripherals are a rarity, an edge case.
There is a planned design to allow the user to grant extra privileges to
different Activities, but those privileges will probably never extend to
loading arbitrary kernel modules. I have no problem declaring that anyone
who is modifying the kernel is a "developer", and should therefore get a
devkey and call modprobe themselves.
- --Ben

Yes.

oo--JS.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC
cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb
=WJse
-----END PGP SIGNATURE-----
_______________________________________________
Security mailing list
Security at lists.laptop.org
http://lists.laptop.org/listinfo/security

[Jay Sulzberger]

Post by Deepak Saxena

Post by Carl-Daniel Hailfinger

Post by Michael Stone
We have an activity that wants superuser privilege in order to poke
kernel memory.

Hello? Please take the poor activity out back and shoot it. No activity
has any business poking kernel memory.

- An activity requires a specific device driver module to be (un)loaded
to properly function and loading this driver requires su privilege.
- An activity requires a device to switch operation modes and that
operation mode is configured via a sysfs file. The file is poked
by a library API, but it requires su privilege to do so.
I agree with Paul that we need to have a solution to these
cases iff we want to support running arbitrary software and
hw combinations on the XO. The other option is to limit the
scope of the system to a very specific set of sw and hw,
treating the XO as embedded education appliance instead of
a general-purpose laptop device, which I don't think
we want to do.

It can be a general purpose laptop. And we need not surrender
our common sense: if we want the thing to be better, it will have
to be different. In particular, it cannot have kernel modules
promiscuously loaded and unloaded. Thus not all software will
run on the laptop. But that is already the case for the most
widely distributed home systems: a Microsoft program will not run
on GNU/Linux, an Apple program will not run on a Microsoft OS,
etc..

Post by Deepak Saxena
I don't have any immediate answers to any of Michael's questions
but I think looking at how the standard ditros deal with this
would be a starting point.
~Deepak

The usual free Unices' security apparatus is ludicrously
inadequate. The XO system should be much better.

oo--JS.

Post by Deepak Saxena
--
Deepak Saxena <dsaxena at laptop.org>
_______________________________________________
Security mailing list
Security at lists.laptop.org
http://lists.laptop.org/listinfo/security