[OLPC Security] Thoughts on bitfrost capabilities, enforcement, and ACLs

[Marcus Leech]

Here's a skeletal python snippet for ACLs in support of bitfrost
capabilities. Thoughts would be most welcome.

#
# Thoughts on ACLs and bitfrost capabilities
#
# Some of the bitfrost capabilities could be implemented by adding ACLs to
# the appropriate filesystem bits, including relevant entries under /dev
#
# For example, /dev/video0 could be owned by root, mode 0600, with ACLs
added
# and removed dynamically as activities come and go that require video
# access ('use_camera').
#
# The appropriate audio device (/dev/dsp?) could be mode 0622, which
would only
# allow opening for write for any random process, and an ACL could be
added
# when an activity that has 'use_microphone' enabled is launched. The ACL
# would allow read/write access, rather than the usual write-only.
#
# The alternative is to have activity launch simply change the ownership
# and/or permissions of the relevant device(s) on launch. But this
precludes
# sharing (which, I admit, may not make sense for devices).
#
# A downside to the ACL approach is that the rainbow daemon would need to
# keep track for purposes of "garbage collection" on ACL entries.
#
import subprocess

def adduser_acl(path, uid, perms):
acl = "u:%d:%s" % (uid, perms)
args = ['setfacl', '-m', acl, path]
subprocess.check_call(args)

def deluser_acl(path, uid):
acl = "u:%d" % uid
args = ['setfacl', '-x', acl, path]
subprocess.check_call(args)


-------------- 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/20071106/b3bacfec/attachment.pgp

[Ivan Krstić]

Post by Marcus Leech
# The alternative is to have activity launch simply change the
ownership
# and/or permissions of the relevant device(s) on launch.

The simple first pass solution is to make the devices owned by a
group ('audio', 'camera') and add activities to the proper group at
launch time if they possess the requisite permissions.

I received a lot of pushback from the OLPC security working group on
the time-based permissions ("you can now use the camera until after
30 minutes of inactivity"), so it's not entirely clear to me yet
whether we'll implement it, though if we do, ACLs would be my
preferred approach. Cheers,

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org

[Marcus Leech]

The simple first pass solution is to make the devices owned by a group
('audio', 'camera') and add activities to the proper group at launch
time if they possess the requisite permissions.

Yup, that works. I like that *nix has a number of different ways of
accomplishing most tasks.

I received a lot of pushback from the OLPC security working group on
the time-based permissions ("you can now use the camera until after 30
minutes of inactivity"), so it's not entirely clear to me yet whether
we'll implement it, though if we do, ACLs would be my preferred
approach. Cheers,

The problem with the "time based" requirement is that enforcing it is
really tricky. You could have the rainbow daemon keep track
of timeouts, and change permissions on objects. But that doesn't
affect a process that already has an open file-handle on that object,
only new attempts to open the object. Now, you could force the apps
to go through an abstraction layer that does all of this,
but that doesn't protect you against malicious code that does "raw" OS
calls, etc.


-------------- 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/20071106/01e491c1/attachment.pgp

[Michael Stone]

Post by Marcus Leech
The problem with the "time based" requirement is that enforcing it is
really tricky. You could have the rainbow daemon keep track
of timeouts, and change permissions on objects. But that doesn't
affect a process that already has an open file-handle on that object,
only new attempts to open the object. Now, you could force the apps
to go through an abstraction layer that does all of this,
but that doesn't protect you against malicious code that does "raw" OS
calls, etc.

Dave Woodhouse suggested, and I concur, that the most straightforward
way to deal with this [should we choose to do so] is to add some
device-specific ioctls() that Rainbow can use to turn the device on and
off per-uid.

Michael

[Marcus Leech]

...especially since there are really only two device (driver)s which
need to be modified in this way. We don't need a general-purpose
revocation mechanism, just a way to revoke these two devices.

Now, there are two devices. Tomorrow, who knows? But I'll agree that
for the special-case of
/dev/{audio,dsp,whatever} and /dev/video0, an ioctl could be added.

We don't even need the 'per-uid' business -- we can just add one 'turn
off' ioctl that anyone with an open file handle could call. We dup2
the file descriptor before giving it to the activity, and rainbow
holds its copy of the handle ready to perform the ioctl at the
appropriate time.
--scott

That certainly would deal with the "you have the mike, but only for 30
seconds" problem, but it might
also open up abilities for malware to cut off access to the
mike/video/whatever.

Have you thought about the semantics of "unspringing" the trap created
by this ioctl()?



-------------- 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/20071106/36760e75/attachment.pgp