[OLPC Security] qmail security

[C. Scott Ananian]

A very enlightening paper on security in qmail, with highly relevant
application to our bitfrost implementation.
http://cr.yp.to/qmail/qmailsec-20071101.pdf
--scott

[Michael Stone]

Ivan and I reviewed briefly reviewed this paper together the day it was
released. Which parts did you find to be most relevant? Which parts did
you have questions about?

Michael

Post by C. Scott Ananian
A very enlightening paper on security in qmail, with highly relevant
application to our bitfrost implementation.
http://cr.yp.to/qmail/qmailsec-20071101.pdf
--scott

[C. Scott Ananian]

Post by Michael Stone
Ivan and I reviewed briefly reviewed this paper together the day it was
released. Which parts did you find to be most relevant? Which parts did
you have questions about?

I thought the concrete description of the UNIX api for strictly
limiting permissions for subprocesses a useful checklist (are we
applying all of these limits?) and, in general, I thought it similar
enough to our implementation strategy to be worth a mention on
whatever wiki pages document our implementation (are there any?).

It seems like making as much as possible of the datastore and sugar
'untrusted code', for example, would be very wise. It would also be
worthwhile to audit our code for uses of 'system' and 'subprocess' and
replace as many as possible of the forked processes with some
'safe_fork' function which limited permissions in the same way
pnmtojpeg was encapsulated.
--scott

[Marcus Leech]

Post by C. Scott Ananian
I thought the concrete description of the UNIX api for strictly
limiting permissions for subprocesses a useful checklist (are we
applying all of these limits?) and, in general, I thought it similar
enough to our implementation strategy to be worth a mention on
whatever wiki pages document our implementation (are there any?).

Some of the resource-limiting stuff Michael and I have been playing with
in experimental
versions of sugar, although independently arrived-at.

Using resource limits to do "damage control" only works if you can
reliably predict what
the "normal" resource constraints are of a controlled process. In
Dans jpegtopnm example,
it's very easy to characterize the processes "expected" resource
profile. It only needs
stdin and stdout available, and should *never* fork a new process.
But it gets more
complicated really quickly with other types of applications (Browse,
eToys, etc).

Post by C. Scott Ananian
It seems like making as much as possible of the datastore and sugar
'untrusted code', for example, would be very wise. It would also be
worthwhile to audit our code for uses of 'system' and 'subprocess' and
replace as many as possible of the forked processes with some
'safe_fork' function which limited permissions in the same way
pnmtojpeg was encapsulated.
--scott

Limiting trusted code is definitely a useful exercise. But the rather
simple pnmtojpeg model
in djbs paper is difficult to map in a fully general way to all of our
applications.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/security/attachments/20071220/81af8eb9/attachment.pgp