[maemo-developers] Security Guidance for N800 OS development

[From: Gustavo Sverzut Barbieri]

On 2/22/07, Eero Tamminen <eero.tamminen at nokia.com> wrote:
> 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?

yes, but the most harmful action is to add "/" to be scanned, but
that's in blacklist so it's avoided.

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbieri at gmail.com
   MSN: barbieri at gmail.com
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
 Phone:  +1 (347) 624 6296; 08122692 at sip.stanaphone.com
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net