[maemo-developers] Monitoring file updates (was: Security Guidance for N800 OS development)
From: Eero Tamminen eero.tamminen at nokia.comDate: Fri Feb 23 09:58:48 EET 2007
- Previous message: Security Guidance for N800 OS development
- Next message: Monitoring file updates (was: Security Guidance for N800 OS development)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Security Guidance for N800 OS development
- Next message: Monitoring file updates (was: Security Guidance for N800 OS development)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
