No, these issues are not present in 2.6 (using the debian 2.6.8 and the
debian kernel-patch-vserver, both from sarge). I am trying to find out if
this is a kernel problem with the debian 2.4.27 kernel in sarge, or a
vserver patch problem.
micah
> Hello
>
> To me it would be good to know if any of these issues are valid
> if you use 2.6 kernel and patch from sarge?
>
> Regards,
>
> // Ola
>
> On Thu, Oct 13, 2005 at 07:00:27PM +0800, Andrew Lee wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear Micah,
>>
>> Thank you for your tests, I have downloaded the testfs-0.11.sh and did
>> the similar tests as yours to help confirm the results.
>>
>> > Test #1
>> > Using all debian sarge componants:
>> > kernel-source: 2.4.27-10 (debian sarge)
>> > util-vserver: 0.30-204-5sarge2 (debian sarge)
>> > kernel-patch: 1.9.5.3 (debian sarge)
>> >
>> > 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
>> > tests show.
>> >
>> > Conclusion: either the fixes to testfs caused error 114 and 124 to go
>> > away, or you have a different kernel-source or kernel-patch applied.
>> > Either try again with testfs.sh-0.11 or install the latest sarge
>> kernel
>> > source and kernel-patch-vserver as those versions are all that matter
>> here.
>>
>> I am using all deian sarge componats, all the same version as yours,
>> and then did the testfs.sh-0.11 by this way(I've setup a loopback file
>> on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
>> barrier has proper setup(I also did this in my other tests later):
>> # ls -lda /var/lib/vservers
>> d--------- 8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>> # showattr -d /var/lib/vservers/
>> - ---BU-- /var/lib/vservers/
>> # lsattr -d /var/lib/vservers
>> - ---------------t- /var/lib/vservers
>>
>> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.27-10vserver-confirm i686/0.30.204
>> VCI: <none> (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> Same fails as you got, and I guess Bertl forgot to change the version in
>> the script, so the script is still showing [V0.10].
>>
>> I also tested the exploit:
>>
>> # ./rootesc
>> Exploit seems to work. =)
>> #
>> And then I can be able to access the host, for example, I can see the
>> vserver's config file on host:
>> # ls -ald /etc/vservers /var/lib/vservers/
>> drwxr-xr-x 4 root root 4096 Sep 22 14:10 /etc/vservers
>> d--------- 8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>>
>> > Test #2
>> > Using only debian sarge util-vserver:
>> > kernel-source: 2.4.31 (upstream)
>> > util-vserver: 0.30-204-5sarge2 (debian sarge)
>> > kernel-patch: 1.2.10 (upstream)
>> >
>> >
>> > 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed
>> using
>> > all debian sarge componants in test #1.
>> >
>> > Conclusion: based on the results from this test, and the previous, it
>> is
>> > clear that the debian kernel source and the debian kernel patch dont
>> > make a difference here
>>
>> Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
>> vserver patch 1.2.10 (upstream)
>> util-vserver: 0.30-204-5sarge2 (debian sarge)
>>
>> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.31-vs1.2.10 i686/0.30.204
>> VCI: <none> (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]* [104]* [106]* [108]. [109]*
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]* [122]* [123]. [124]. [199].
>>
>> Same result as you got, seems the testfs #1 and #2 shows no difference,
>> but the exploit works on #1's setup, not on #2.
>>
>> # ./rootesc
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> (alternating a few times)
>> then the false:
>> Exploit seems to work. =)
>> (because it always shows this line, actually it failed, but nobody
>> bothered to fix up the exploit bug)
>>
>> > Test #3
>> > Using debian sarge componants with upstream util-vserver:
>> > kernel-source: 2.4.27-10 (debian sarge)
>> > util-vserver: 0.30-208+fix03 (upstream)
>> > kernel-patch: 1.9.5.3 (debian sarge)
>> >
>> > Only test 106 fails... Not 104, 114, 122 or 124.
>> >
>> > Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
>> > away or you have a different kernel-source or kernel-patch applied,
>> try
>> > with testfs.sh-0.11 to see, or just try with a current sarge kernel
>> and
>> > patch since that is all that matters here.
>>
>> In your test #3, you used the 0.30-208+fix03 from upstream, and I am
>> using the one from sid, let's see any difference:
>> I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
>> also to be upgraded). These are the messages I got:
>> Setting up util-vserver (0.30.208-3) ...
>> Installing new version of config file /etc/init.d/rebootmgr ...
>> Installing new version of config file /etc/init.d/vprocunhide ...
>> Installing new version of config file /etc/init.d/vservers-legacy ...
>> /var/lib/vservers: Operation not permitted
>>
>> For the error message, I don't know what is wrong in postinst script,
>> but after I looked at the script, I found:
>> - ---
>> # Remove older attr +t if present
>> if [ "`lsattr -d /var/lib/vservers/|cut -c16`" = "t" ] ; then
>> chattr -t /var/lib/vservers
>> fi
>>
>> # set chroot barrier
>> setattr --barrier /var/lib/vservers || true
>> - ---
>> I think this is wrong, let me quote what Bertl explained to me:
>> <quote>
>> 19:53 < Bertl> (on 2.4 it is important that you verify the following)
>> 19:54 < Bertl> the directory permissions _are_ 000, the barrier 'B' and
>> iunlink'U' is reported, the 't' flag shows up
>> 19:54 < Bertl> ('U' and 't' are connected on 2.4)
>> </quote>
>> I will file another bug to util-vserver later.
>>
>> Let me go back to do the test #3:
>> kernel-source: 2.4.27-10 (debian sarge)
>> util-vserver: 0.30-208-3 (debian sid)
>> kernel-patch: 1.9.5.3 (debian sarge)
>> # ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.27-10vserver-confirm i686/0.30.208
>> VCI: <none> (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> Same as yours, only test 106 fails. And the exploit works here still:
>> # ./rootesc
>> Exploit seems to work. =)
>> # ls -lad /etc/vservers /var/lib/vservers/
>> drwxr-xr-x 4 root root 4096 Sep 22 14:10 /etc/vservers
>> d--------- 8 root root 4096 Oct 13 15:37 /var/lib/vservers/
>>
>>
>> > Test #4
>> > Using all upstream componants:
>> > kernel-source: 2.4.31 (upstream)
>> > util-vserver: 0.30-208+fix03 (upstream)
>> > kernel-patch: 1.2.10 (upstream)
>> >
>> > Only test 106 fails, same as the previous test, when we use the debian
>> > sarge kernel-source and kernel-patch.
>> >
>> > Conclusion: Based on the results of this test, and the previous, it is
>> > clear that the debian sarge kernel source and debian sarge kernel
>> patch
>> > don't make a difference here either, the problem has been isolated to
>> > util-vserver 0.30-204-5sarge2 in sarge. If this is actually a problem,
>> I
>> > do not know, this definatetly needs to be determined. Additionally,
>> test
>> > 106 could be in error, this should also be checked.
>>
>> In my test, I am still using the util-vserver from sid:
>> kernel-source: 2.4.31 (upstream)
>> util-vserver: 0.30-208-3 (Debian sid)
>> kernel-patch: 1.2.10 (upstream)
>>
>> ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
>> Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
>> Linux 2.4.31-vs1.2.10 i686/0.30.208
>> VCI: <none> (unknown)
>> - ---
>> testing ext2 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> - ---
>> testing ext3 filesystem ...
>> [000]. xattr related tests ...
>> [101]. [102]. [103]. [104]. [106]* [108]. [109].
>> [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
>> [121]. [122]. [123]. [124]. [199].
>>
>> Same as you got, only fails on 106.
>> And exploit doesn't work:
>> # ./rootesc
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> cd ..: Permission denied
>> chmod: Operation not permitted
>> (alternating a few times)
>> then the false:
>> Exploit seems to work. =)
>>
>> > The above tests are only done with ext2, I am not sure why you didn't
>> do
>> > the xfs, reiserfs and jfs tests, but there is no need, as I have done
>> them:
>> >
>> > Conclusion: using *all* upstream pieces, the same failures occur when
>> > using debian kernel source and kernel patch. This leads me to believe
>> > that either the upstream kernel source is broken, the upstream linux
>> > vserver patch is broken, or most likely the testfs is not working
>> > properly for these tests.
>>
>> I do not know, the different I found is the exploit works only in
>> 2.4.27-10 with kernel-patch-vserver 1.9.5.3 (debian sarge), but not with
>> vanilla kernel with upstream patch.
>>
>> I didn't test reiserfs, xfs and jfs, cause I knew some futures only
>> implemented on ext2/3(eg:disklimit), so I only focus my tests on ext2/3.
>>
>> Let me know if you need more tests on my side for investigate this
>> problem.
>>
>> Thank you very much for investigating this issue.
>>
>> Best regards,
>>
>> - -Andrew
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2 (GNU/Linux)
>>
>> iD8DBQFDTj5HnQYz4bYlCYURAlo+AJ0TAmp0+59cHvSWE84dteBb3FMYQACfY3oB
>> btznLu/i+MP6KlLdGCLzlxY=
>> =SK9G
>> -----END PGP SIGNATURE-----
>>
>>
>
> --
> --------------------- Ola Lundqvist ---------------------------
> / [EMAIL PROTECTED] Annebergsslingan 37 \
> | [EMAIL PROTECTED] 654 65 KARLSTAD |
> | +46 (0)54-10 14 30 +46 (0)70-332 1551 |
> | http://www.opal.dhs.org UIN/icq: 4912500 |
> \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
> ---------------------------------------------------------------
>
>
>
