Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
On Fri, 20 Jan 2006, Sam Morris wrote: > AFAIK Linux only supports eight loopback mounts at a time. This > won't be a problem once FUSE becomes more widespread. The default is 8; by seting the max_loop kernel option, you can increase this to 256. Don Armstrong -- "You have many years to live--do things you will be proud to remember when you are old." -- Shinka proverb. (John Brunner _Stand On Zanzibar p413) http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
Sam Morris wrote: > If suidperl does not ensure that the scripts it interprets have the suid > bit set, then shouldn't a critical bug be filed? The nosuid mount option does not cause the suid bit to be unset, it causes the kernel to not honor it when executing binaries. This doesn't work for programs like suidperl that deal with suid bits on their own. With that said, suidperl has been modified since that man page was written to detect nosuid filesystems on its own: [EMAIL PROTECTED]:/tmp>./foo.pl Setuid script "./foo.pl" on nosuid filesystem. -- see shy jo signature.asc Description: Digital signature
Re: Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
> > Please try "man mount". If your manpage is similar to mine, it will
> > contain something like:
> >
> > snip --
> > OPTIONS
> >user 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.
I do.
But if I have suidperl(1) installed on my (multiuser) system, then I have
bigger fish to fry than just the klik ones anyway. Then practically every
script can be tricked into setuid execution of all criminal commands you
want.
So... you are right here.
> 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.
Yes. ("root privileges" -- meaning a sudoer user can also install the klik
client and modify the fstab).
> 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?
It means that no more than 7 klik .cmg apps can be used concurrently by
the default klik client installations. No more than 7 concurrent loop
mounts by mortal users.
Actually, the kernel limit is 8. But klik leaves generously one over for
other uses (such as Knoppix) ;-)
> Either way, it seems quite
> artificially limiting.
Yes.
I said so in an earlier posting:
We know this is ugly (and a big limitation) -- but
once Kernel 2.6.14 with FUSE will become more widespread,
this will no longer be required.
It is just the way that loopmounting is limited. You can tune it up to 32
concurrent mount points, by editing the config file and using the appropriate
kernel parameter for booting.
> If I have an 8th user who wants to use klik, what
> do I do?
Whatever you prefer: :-)
* kick off one user
* reboot with a tuned setting
* install a 2.6.14 Kernel with FUSE support (and install the
experimental modifications to klik to make use of it).
(well, the 8th is still easy. The problem starts with the 9th, or the 33th...)
> - Matt
Cheers,
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
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 0 Doesn'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 -- OPTIONS user 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
On Fri, Jan 20, 2006 at 03:59:23PM +, Kurt Pfeifle wrote: > Wouter Verhelst wrote on debian-devel@lists.debian.org: > > [Re-adding Cc to Kurt, as he's mentioned he isn't subscribed] > > > > On Fri, Jan 20, 2006 at 01:20:26PM +0800, Cameron Patrick wrote: > > > Kurt Pfeifle 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 > > > > 0 > > > > > > Doesn'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 -- > OPTIONS >user 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. 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? - Matt
