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

[From: Gustavo Sverzut Barbieri]

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

I've replyied in another mail, but here it goes: some users may have
maemo on MMC/SD and media under /var/media or /var/lib... but ok, it's
a rare case. I'll make this blacklist came from GConf, pre-defined
with /tmp, /var and others except /home and /media


> 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).

It's kinda hard to implement whiltelist for end-user (or not security
aware user) applications. Users tend to want things their ways, you
cannot force them and tell our way is right, just check
https://garage.maemo.org/tracker/?func=detail&atid=529&aid=499&group_id=125

Anyway, it's a blacklist to let user choose his whitelist... We just
scan what user choose.


> 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

Actually we listen for GnomeVFS DBus events: mount, unmount and pre-unmount.

pre-unmount is used to let us copy canola.db to it before it's
unmounted. It's used to let PC applications like syncropated to
configure existing DB (it read from existing tables and then store SQL
queries on backlog table, that will be executed by canola, not used so
far).

So, canola-conf can cause problems while copying canola.db, but just
if user force removal, since filesystem isn't unmounted if there are
open files.


> [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

Yeah, we've experienced some, but most were due using SWAP on MMC.

Anyway, N800 should reduce these problems and copy of canola.db to mmc
may vanish if required.

Thanks for feedback!

-- 
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