[Vserver] dpkg fails when upgrading hashified setuid files
this email is to serve as a notification of a problem and a survey of possible workarounds/solutions. the problem: when using dpkg to upgrade a package that contains setuid/gid files which have been unified/hashified, dpkg wants to first chmod 600 the files before unlinking them (in case somebody has hardlinked to a security susceptible file which will remain even after the upgrade because of the hardlink). of course, as the files are immutable, the chmod fails, but this behavior is never seen for all other files because dpkg unlinks them without chmoding them first (and unlinking is allowed). the problem exhibits itself as such: dpkg: error processing /var/cache/apt/archives/passwd_1%3a4.0.3-31sarge8_amd64.deb (--unpack): failed to rmdir/unlink `//usr/bin/chage.dpkg-tmp': Operation not permitted the relevant line in an strace: 6516 chmod(//usr/bin/chage.dpkg-tmp, 0600) = -1 EPERM (Operation not permitted) sam vilain brought up this issue 4 years ago in http://lists.debian.org/debian-dpkg/2002/06/msg00105.html. more recently i think sebd encountered this problem and shared it with herbert in irc, recorded in http://irc.13thfloor.at/LOG/2005-03/LOG_2005-03-19.txt. this is especially problematic because currently dpkg emits an error, aborts the upgrade, and returns a non-zero exit status, but lists the new package version as being installed without error (though none of the new files were installed). i reported this bug at http://bugs.debian.org/382760. one solution is to manually remove all setuid/gid files before upgrading them (which i did before tonight when i would have had to do that for a dozen files on 14 vservers due to upgrading login passwd packages; that crossed my threshold). but that still doesn't deal with the security implication brought up by ben collins in response to sam vilain's email. that's not a major concern for me because currently i only use vservers as personal per-process super chroot's, so if somebody besides me is creating hardlinks to setuid files, and believe me i'm not, then i already have bigger security problems. but if i should ever want to provide semi-public user-level access to my vservers, then what are my options? how do other distros address this problem, or do they ignore it or are unaware of it? i'm currently implementing the workaround as a patch to dpkg disabling the chmod. that's good enough security-wise for my particular need. it means i'll have to maintain the patch against dpkg and build a new package every time dpkg is updated, but i run stable (currently sarge) on my server and in my vservers, so it shouldn't happen that frequently. i thought about writing a wrapper around dpkg, but that would be fairly complex as dpkg accepts a lot of different options that i would have to take into consideration and i would have to insure the unique interaction between apt-get and dpkg didn't break. so what are other people doing to work around this problem? is this not an issue for anybody else because i'm the only debian user with unified/hashified vservers? corey -- [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Multiple NICs, Multiple Networks; Revisited 2
On Sat August 12 2006 02:14, Bob Predaina wrote: eth0, eth1, eth2 and lo are all up and running on the host. the host is using eth0. as a test setup i have installed two guest servers that will be using eth1. both were created using the --interface eth1:192.168.18.252/24 parameter. Have you tried specifying a single address? --interface eth1:192.168.18.252/32 The guests correctly report that they are using eth1 at 192.168.18.252. Even though the guest server's ifconfig information shows binding to the correct ethernet adapter and IP address (eth1:192.168.18.252), it appears that they are responding to incoming traffic on eth1:192.168.18.252, but their outgoing traffic is actually going out through eth0:192.168.18.251. there is no isolation of the network interfaces. Both of those addresses are within the eth1:192.168.18.252/24 specification. Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Multiple NICs, Multiple Networks; Revisited 2
Hi Bob. After reading both this thread and the one on the Gentoo forums that you posted, I see several problems. First, I would use seperate subnets for each of your eth0, eth1, and eth2 interfaces, and of course, seperate hubs/switches. I tried for a week to get 2 nics working on the same subnet and never got past the routing problems. For isolation reasons, I wouldn't expect that you would even really want them on the same subnet anyway. Second, it sounds like you are trying to use the same ip for your guest as the ip that you have set for your real interface. The guest os should have a unique address on the same subnet that the real interface is on. For instance, if eth1 has an ip of 192.168.18.252, then your guest os can have an ip of 192.168.18.100. Assuming that 192.168.18.100 is not already in use elsewhere. This leads to the third problem. Every guest os must have a unique ip address. In reading your posts, it sounds like you are trying to use the same ip for multiple guests. You can't do that. :) John On 8/13/06, Michael S. Zick [EMAIL PROTECTED] wrote: On Sat August 12 2006 02:14, Bob Predaina wrote: eth0, eth1, eth2 and lo are all up and running on the host. the host is using eth0. as a test setup i have installed two guest servers that will be using eth1. both were created using the --interface eth1:192.168.18.252/24 parameter. Have you tried specifying a single address? --interface eth1:192.168.18.252/32 The guests correctly report that they are using eth1 at 192.168.18.252. Even though the guest server's ifconfig information shows binding to the correct ethernet adapter and IP address (eth1:192.168.18.252), it appears that they are responding to incoming traffic on eth1:192.168.18.252, but their outgoing traffic is actually going out through eth0:192.168.18.251. there is no isolation of the network interfaces. Both of those addresses are within the eth1:192.168.18.252/24 specification. Mike ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Multiple NICs, Multiple Networks; Revisited 2
On Sunday 13 August 2006 16:52, John Alberts wrote: This leads to the third problem. Every guest os must have a unique ip address. In reading your posts, it sounds like you are trying to use the same ip for multiple guests. You can't do that. :) You CAN share IP addresses between multiple guests, but unless you have a good reason to do so you shouldn't. The reason why it is discuraged is because each guest can disturb the other one by taking over ports. E.g. in first guest you start sshd, in second guest you can't do so anymore unless you run sshd on different ports for both guests. Regards, Bruno ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] dpkg fails when upgrading hashified setuid files
On Sun, 13 Aug 2006 03:41:35 -0500 Corey Wright [EMAIL PROTECTED] wrote: the problem: when using dpkg to upgrade a package that contains setuid/gid files which have been unified/hashified, dpkg wants to first chmod 600 the files before unlinking them (in case somebody has hardlinked to a security susceptible file which will remain even after the upgrade because of the hardlink). of course, as the files are immutable, the chmod fails, but this behavior is never seen for all other files because dpkg unlinks them without chmoding them first (and unlinking is allowed). one solution to the security issue that i forgot to mention is to keep user-writable directories on seperate file systems than setuid/gid files as hardlinks cannot cross file systems. i implement this philosophy on all my larger installations (ie the vserver host, my workstation), but i haven't done this within vserver guests because there are no user directories (ie /home/*) and most of my guests are small (= 200 MB as they merely provide a single service, not host tons of data). it seems somewhat cumbersome, though definitely doable, to have two partitions in every vserver with user-level access, especially for smaller vservers. are there any other options? corey -- [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Files lost in guestsystem
Hello, I lose files in the guest system (debian/fc3) in the host i could see them why?? -config error?? -could i get them back?? -it seem it happends if i touch them from the host 2. trouble bind is not working vi /etc/vservers/dns/bcapabilities NET_BIND_SERVICE NET_ADMIN NET_RAW SYS_ADMIN SYS_BOOT SYS_NICE CAP_SYS_RESOURCE node4 ~ $ vserver dns start Starting named: named: capset failed: Operation not permitted: please ensure that the capset kernel module is loaded. see insmod(8) system: fc3 kernel: 2.6.17.7-vs2.0.2 util-vserver 0.30.210 Thanks for help Roman ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] 2.6.17.7 kernel oops
Hello, I tried to run 2.6.17.7 with the 2.0.2-rc28 patch from vserver.13thfloor.at/Experimental but it oopsed when starting init (and it didn't go on anymore after that), 2.6.17.6 with the 2.0.2-rc26 patch worked fine (which was for 2.6.17.4 but only makefile had to be adjusted). Perhaps it's something obvious... I'm doing this inside vmware. Kernel config available on request, perhaps even the kernel log (if needed, but then I'll need to reboot into the new/old kernel) - more info from sid3windr @ #vserver as well... Thanks, Tom ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] interpretation of igneg_nice (Mailscanner not starting up)
On Fri, Aug 11, 2006 at 10:22:24AM +0200, Thorsten Büker wrote: Dear all, The daemon mailscanner (http://www.mailscanner.info/) is not starting up during the boot process of a vserver using the original script inside vserver's /etc/init.d/, linked from /etc/rc2.d for sure ;-) Changing the relevant lines from /usr/bin/nice -$run_nice start-stop-daemon --start --quiet \ --exec $DAEMON /dev/null 21 to start-stop-daemon --start --quiet --nicelevel $run_nice \ --exec $DAEMON /dev/null 21 at least fixes the problem during the startup of the vserver. But as Mailscanner uses to restart itself periodically, it stops running at this moment. I don't prefer to fix all calls as shown above to stay compatible with future updates. Google led me to these pages: - http://www.tgunkel.de/it/software/doc/linux_server - http://linux-vserver.org/linux-vserver_administrators_guide - http://linux-vserver.org/Caps+and+Flags I tried the line IGNEG_NICE in /etc/vservers/mail/flags as well as the line CAP_SYS_NICE in /etc/vserver/mail/bcapabilities. But both options didn't lead to success, yet. Has anybody an idea? Btw, we are talking about 2.6.17.7-grsec2.1.9-vs2.0.2-rc26. well, either grsec is blocking you here, or you are doing something wrong, here is a test for 2.0.x and 2.1.x to verify that feature: 2.0.x: NOCAPS=vcmd -i -1 -BC set_ccaps_v0 bcaps=0 -- ENDINI=vcmd -i -1 -BC set_cflags .mask=^32 -- vcmd -i 42 -BC ctx_create .flagword=^34^32^8 -- $NOCAPS $ENDINI renice -10 $$ renice: 20: setpriority: Permission denied vcmd -i 42 -BC ctx_create .flagword=^52^34^32^8 -- $NOCAPS $ENDINI renice -10 $$ 20: old priority 0, new priority 0 ~~ as you can see, the priority raise was _simply_ ignored and for 2.1.x you simply use: NOCAPS=vcmd -i -1 -BC set_bcaps .bmask=~0 -- instead of the above, with the same vcmd commands ... vcmd is a hack tool, designed for testing the vserver API, you can find it here: http://vserver.13thfloor.at/Experimental/TOOLS/vcmd-0.04.tar.bz2 HTH, Herbert kind regards, thanks in advance, Thorsten ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vserver fubar build -m yum is not working for me.
On Fri, Aug 11, 2006 at 12:51:35PM -0400, Gregory L Miller-Kramer wrote: TWIMC, (To Whom It May Concern) I have done this before (VServers and CentOS) and I have created quite a few VServers in the past. So, I am retracing familiar steps. I installed CentOS 4.3, NO SELinux, and no GUI. I followed the best set of steps for creating a CentOS VServer Host. (http://linux-vserver.org/CentOS_HowTo and http://linux-vserver.org/Step-by-Step+Guide+2.6) I do the step where I will be taking a coffee break :-) while the host downloads (and installs) all the RPM's via Yum and it fails. So, no coffee :-( . vserver min-centos4 build -m yum --hostname domain.com --interface domain=eth0:192.168.0.136/24 --initstyle sysv --context 500 --force -- -d centos4 I get this... rpm-fake-resolver: vc_ctx_migrate(): No such process rpm-fake.so: failed to initialize communication with resolver could you run testme.sh and add the output here too? I have looked throughout google and the vserver lists but nothing useful. This did work about 2 months ago because I followed the steps and was able to do it when I created another machine. The machines are physically different but I don't see how that would cause this. I used dietlibc and when I did the configure of 0.30.210 (util-vserver) I get this. ( it is long, sorry) [EMAIL PROTECTED] util-vserver-0.30.210]# ./configure --prefix=/usr --sysconfdir=/etc --with-vrootdir=/vservers checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking whether gcc and cc understand -c and -o together... yes checking whether g++ is a C++ compiler... yes checking whether gcc is a C99 compiler... yes checking for awk... /bin/awk checking for cat... /bin/cat checking for chown... /bin/chown checking for cmp... /usr/bin/cmp checking for cp... /bin/cp checking for dirname... /usr/bin/dirname checking for egrep... /bin/egrep checking for env... /bin/env checking for grep... /bin/grep checking for ln... /bin/ln checking for mkdir... /bin/mkdir checking for mkfifo... /usr/bin/mkfifo checking for mktemp... /bin/mktemp checking for mount... /bin/mount checking for mv... /bin/mv checking for nice... /bin/nice checking for ps... /bin/ps checking for rm... /bin/rm checking for rmdir... /bin/rmdir checking for sed... /bin/sed checking for sh... /bin/sh checking for tac... /usr/bin/tac checking for tar... /bin/tar checking for touch... /bin/touch checking for tty... /usr/bin/tty checking for umount... /bin/umount checking for wc... /usr/bin/wc checking for ip... /sbin/ip checking for iptables... /sbin/iptables checking for modprobe... /sbin/modprobe checking for nameif... /sbin/nameif checking for nohup... /usr/bin/nohup checking for rmmod... /sbin/rmmod checking for vconfig... /sbin/vconfig checking for wget... /usr/bin/wget checking for doxygen... /usr/bin/doxygen checking for xsltp... no checking for xsltproc... /usr/bin/xsltproc checking whether the C-compiler accepts -Werror -W... yes checking whether gcc accepts -std=c99... yes checking whether gcc accepts -Wall... yes checking whether gcc accepts -pedantic... yes checking whether gcc accepts -W... yes checking whether the C++-compiler accepts -Werror -W... yes checking whether g++ accepts -ansi... yes checking whether g++ accepts -Wall... yes checking whether g++ accepts -pedantic... yes checking whether g++ accepts -W... yes checking whether g++ accepts -fmessage-length=0... yes checking whether to enable extra optimizations... yes checking whether gcc accepts -funit-at-a-time... yes checking whether g++ accepts -funit-at-a-time... yes checking whether to enable debug-code in library... no checking whether to enable expensive tests... no checking for declarations in linux/personality.h... checking whether MMAP_PAGE_ZERO is declared... yes checking whether ADDR_LIMIT_32BIT is declared... yes
