[maemo-developers] Security Guidance for N800 OS development

[From: Eero Tamminen]

Hi,

ext Gustavo Sverzut Barbieri wrote:
>> >   - canola-conf listen to 127.0.0.1:9000 (can be changed using
>> > GConf), it's a webserver that serves HTML, JS, ... it's written using
>> > libsoup and actions (/actions/ClassName/{get,set}_data and
>> > /actions/ClassName/get_presentation) is written in C, for objects that
>> > implement CnlIConfigure interface, so far I wrote them all. I'm still
>> > not aware of any buffer overflow that could compromise the device.
>> > Worth remembering that it runs as "user", not root.
>>
>> "user" user can do anything in the device that the device owner can
>> through the the device UI, so in practice this does *not* prevent
>> compromised process from doing _anything_ that matters.
>>
>> To be more secure:
>> - run the process e.g. as user "nobody", this way it cannot
>>    ruin user's settings, files, install other SW (through sudo) etc
> 
> we need exactly to access user file /home/user/.canola/* and his gconf
> options :-/

With user nobody, it would still be able to read the files (depending on
the file rights), but that would be very kludgy.  Reading the gconf
options shouldn't(?) be a problem I think as the process needs only to
be able to connect to the D-BUS.


>> - nice the process, so that it cannot take all the CPU
>> - use ulimit so that the process memory usage is limited more
>>    than user application's, otherwise it may be able to get
>>    some of user's apps to abort when memory runs low
>>    - AFAIK kernel OOM-handler should be able to handle fork-bombs too
> 
> that's something to be considered.

IMHO all background services which response time is not crucial should
be at least niced, especially if they handle data that can come from
outside the device.  (metalayer-crawler is a good example of why :))


>> - chroot it to its work directory, so that it cannot read
>>    anything outside it
> 
> you need root access to have that.

Yes, it's a bit extreme, used maybe as the last step...


>> With this it can still fill the Flash which might require user
>> to reflash the device (unless he's a Linux developer who knows
>> how to eliminate the offending the program and find what is taking
>> all the Flash).  Ulimit has a setting for limiting the file sizes,
>> but I'm not sure whether that's enough to prevent process from
>> filling the device Flash.
> 
> We have no reports on it consuming much file space. 770 version uses
> sqlite0, which may need vaccuum that we don't do, but even without it,
> db doesn't grow that big.

Wasn't the question about protecting against something that compromises
the server through its network socket and tries explicitly to
harm/exploit the device?


	- Eero