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
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
