Matthew Palmer wrote:
The klik client installation needs root privileges once, to add 7 lines like this one to /etc/fstab: /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 0Doesn't this introduce a local root exploit? A user can easily write their own /tmp/app/1/image file which contains, say, a setuid root bash executable.Yes, that's exactly what I was afraid of, myself.Please try "man mount". If your manpage is similar to mine, it will contain something like:---------------------------- snip ---------------------------------- OPTIONSuser Allow an ordinary user to mount the file system. The name of the mounting user is written to mtab so that he can un-mount the file system again. This option implies the op- tions noexec, nosuid, and nodev (unless overridden by sub- sequent options, as in the option line user,exec,dev,suid). ---------------------------- snap ----------------------------------Note the part mentioning "nosuid" - and compare it to the fstab line used by klik. :-)You might want to read your manpage a bit more: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)Particularly note the parenthetical sentence.
If suidperl does not ensure that the scripts it interprets have the suid bit set, then shouldn't a critical bug be filed?
On another point, I believe you said earlier that the admin is required to add 7 of those lines to fstab before klik could be used. Does that mean that no more than 7 applications can be installed, or that no more than 7 users can use klik on the one machine? Either way, it seems quite artificially limiting. If I have an 8th user who wants to use klik, what do I do?
Write to lkml. ;) AFAIK Linux only supports eight loopback mounts at a time. This won't be a problem once FUSE becomes more widespread.
- Matt
-- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078