[Server-devel] nocat/internet restriction plans

[Martin Langhoff]

On Thu, Jan 14, 2010 at 7:10 PM, Daniel Drake <dsd at laptop.org> wrote:
> I've read the threads about NoCat and am a little confused about the
> plan for restricting internet access to XOs.

We did discuss various approaches. My thinking is that NoCatAuth is
good as a source of ideas, sample code, etc. After my initial review I
did not consider using it outright.

The winning approach is probably along the lines of keeping our DHCP
scheme, and avoiding the split IPv4 netblocks model -- we have enough
DHCP, netblocks and related confusion already. Using this schemes
means that an XS restart preserves connectivity, as we can preserve
our whitelist.

The key "action" is whitelisting MAC addresses upon successful Moodle
login. This has a few folds...

Moodle login depends on registration _or_ having an account generated
manually. This covers the case of non-XO/non-Sugar laptops for
teachers (who would presumably get an account created with a password
so that they can login with a non-Sugar laptop). We could instead
collect MAC addresses on registration but this leaves non-Sugar
laptops out.

The entry point in Moodle is /var/www/moodle/web/auth/olpcxs/auth.php
if you want to peruse the code. My thought was to create an
"whitelist-new" directory where apache can write, and write a file
with the mac address there; using incron to monitor the directory
trigger a whitelist update (and move the file to a "whitelist-store"
dir).

Inside the Moodle code implementation, I want to make sure we add a
'capability' to control this ("olpcxs/access-internet") and check for
it. It will be set to allowed by default, but moodle admins can turn
it to no for a single user, or for a group of users.

The whitelisting must affect both NAT and the proxy (right now squid).
We need a way to redirect requests to Moodle if you're not on the
whitelist.

This does mean that if you want to run bittorrent you have to open
Browse.xo and at least visit your schoolserver.

You mention ejabberd connection / disconnection, that might also be a
reasonable way to handle the whitelisting, but again it misses
non-sugar users, and does not have the access control features of
Moodle.

As you know I am juggling a dozen balls here, but if you take on this
I'll be more than happy to help with the Moodle bits; as it's a fairly
large and messy API to get familiar with.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff