[maemo-developers] Monitoring file updates (was: Security Guidance for N800 OS development)

From: Eero Tamminen eero.tamminen at nokia.com
Date: Fri Feb 23 09:58:48 EET 2007
Hi,

ext Gustavo Sverzut Barbieri wrote:
>> > yes, but the most harmful action is to add "/" to be scanned, but
>> > that's in blacklist so it's avoided.
>>
>> If it is monitoring file changes in the device, you should also
>> ignore at least /dev & /sys*, otherwise your process wakes up
>> unnecessarily (which drains battery).
> 
> Sure, we ignore:
> 
>    static const gchar *blacklist[] = {
>        "/bin",
>        "/boot",
>        "/dev",
>        "/etc",
>        "/lib",
>        "/proc",
>        "/root",
>        "/sbin",
>        "/sys",
>        "/usr/bin",
>        "/usr/sbin",
>        "/usr/etc",
>        "/usr/lib",
>        NULL
>    };

Any particular reason why you're not ignoring "/var" (where can
be log files etc) and "/tmp" (where are locks, sockets and app state 
data etc) which get often updated?


Btw. As a general security rule (this is not about security but..),
it's better to allow things that are known to be safe and ignore
rest than try to deny things (because that way you will always miss
some new exploits).


If the server is interested only about media files, it's better to
allow only stuff under /home and /media.  And if you're checking
stuff under /media, you SHOULD be promptly reacting to unmount
messages[1] for the media cards.  I've gotten some (unconfirmed)
doubts that if something is blocking memory card unmounting and it
needs to be forced (e.g. at shutdown), that sometimes might corrupt
the FAT[2] filesystem on users' memory cards.

[1] Gconf key updates for:
     - /system/osso/af/mmc-cover-open
     - /system/osso/af/usb-cable-attached
     - /system/osso/af/internal-mmc-cover-open

[1] Microsoft in 80's didn't really "design" FAT to be robust...


And as can be learned from the issues with metalayer-crawler,
inserting a memory card with corrupted FAT can create some
interesting problems unless developer takes extra pains to
handle error cases like:
- infinitely recursing directories and this doesn't mean just ignoring
   (directory) symlinks, but actual (corrupted MMC FAT) filesystem
   directories being recursive
- errors on allocations and with directory/file reads *and* reacting
   correctly to them i.e. not retrying (at least more than couple of
   times), but canceling/unwinding (suitable part of) the operation


	- Eero

More information about the maemo-developers mailing list