[OLPC Security] Mapping BitFrost capabilities into enforcement actions

[Marcus Leech]

I've taken small steps at turning BitFrost capabilities into actions.

I thought about c_scotts idea of mapping 'use-camera' and
'use-microphone' into a processes extended group-id list.  The
  idea is that /dev/camera (or whatever) is in group 'camera', mode
660.  When a process asks for 'use-camera', they get
  the 'camera' group in their extended group list.  Similarly for
/dev/{audio,dspX, etc}, the relevant device file is in group
  'microp', mode 662.  That allows any process to write to the audio
device, but only the owner (root), and processes that
  have 'microp' in their extended group list can open the mike for reading.

So, I have  version of ...rainbow/inject.py and ...rainbow/service.py
that calls Ivans PermissionSet code, and looks
  for 'use-camera' and 'use-microphone' in the permission set, and sets
the extended groups accordingly.  I arbitrarily
  put permissions/capabilities in bundle_path/permissions.info, but they
can go anywhere, I guess.   In VMS,
  which has an extensive set of per-application "capabilities", there
was a central datastore for per-application
  capabilities, with a special editor for that database, etc.   I'm much
happier having the capability sets bunded up
  with the application data, rather than off in some database somewhere.

The next thing I want to look at is quota logic, and mapping it into
os.setrlimit() quotas, but the exact syntax and intended
  semantics of 'quota' in aren't very clear, just from the
PermissonSet() code...

-------------- 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/20071109/217ac54d/attachment.pgp