Re: [Vserver] util-vserver + dietlibc ...
[EMAIL PROTECTED] (Stephen Frost) writes: That's not possible. During the extraction phase, 'rpm' has to do an username - uid mapping with the setup from the inside of the chroot. So at least there, I need getpwname() after chroot(). Sorry for the double-reply but additionally, is that the only place where this issue exists? I'm not even sure what you mean by the 'extraction phase'- do you mean when building the vserver? It is meant the phase when 'rpm --root ...' extracts the files and has to map the username to an uid. If you're building it new it seems unlikely that it's a compramised vserver. 'vrpm' + 'vapt-get' + 'vyum' work long after the initial build also. This might be after the vserver was compromised. Does this affect Debian users at all (who use Debian in their vservers)? Probably not; for Debian only the internal packagemanagement is supported. Enrico pgpNJ4RJ803tT.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
* Enrico Scholz ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (Stephen Frost) writes: It's not uncontrollable- just don't call NSS functions after you've chroot'd. That's not possible. During the extraction phase, 'rpm' has to do an username - uid mapping with the setup from the inside of the chroot. So at least there, I need getpwname() after chroot(). Is this inside the same process context which could get back out of the vserver? Does it need to be? Either there's a serious problem with vservers in general or there's a way to resolve these concerns. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
* Enrico Scholz ([EMAIL PROTECTED]) wrote: That's not possible. During the extraction phase, 'rpm' has to do an username - uid mapping with the setup from the inside of the chroot. So at least there, I need getpwname() after chroot(). Sorry for the double-reply but additionally, is that the only place where this issue exists? I'm not even sure what you mean by the 'extraction phase'- do you mean when building the vserver? If you're building it new it seems unlikely that it's a compramised vserver. Does this affect Debian users at all (who use Debian in their vservers)? Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert Poetzl [EMAIL PROTECTED] writes: no, thanks I already figured it, the dietlibc needs patching as the syscall(2) for x86_64 isn't implemented .o( I wonder _what_ is running on your machine ;) I guess it was using _syscall3() instead of syscall(). Shouldn't it? yes, after I read your 'other' email ... this makes some sense ... I just wondered because I didn't know that it is available on x86_64 (headers) To clearify things: util-vserver prefers to use _syscall3() (which is called 'fast' syscall invocation method in the ./configure output) when it is available. _syscall3() is often implemented with inline assembler in asm/unistd.h. But at least on i386, it can not be used in combination with dynamic linking as it writes to the %ebx register which is reserved for PIC addressing. Therefore, most glibc kernel-headers do not provide the _syscallX() functions overall and the 'traditional' syscall(2) must be used. Enrico pgphpOigxwzJp.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
[EMAIL PROTECTED] (Stephen Frost) writes: according to Enrico (please confirm or correct) the glibc has issues with the fake name resolver and is generally considered insecure because usually dynamically linked ... This really needs further explanation and justification. What about glibc being dynamically linked (and able to load other libraries) makes it insecure, specifically? 1. 'insecure', because the dynamical loading of libnss_* is uncontrollable. There is no (documented??) way to disable this loading e.g. when the chroot was entered. Executing a function which would load an nss-library does not give any guarantee that the next call to this function with another argument would not load another library. It's not uncontrollable- just don't call NSS functions after you've chroot'd. That's not possible. During the extraction phase, 'rpm' has to do an username - uid mapping with the setup from the inside of the chroot. So at least there, I need getpwname() after chroot(). Enrico pgpxCsneViktQ.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Enrico Scholz wrote: Herbert Poetzl [EMAIL PROTECTED] writes: what if we implement the _syscall3 for all known platforms in a proper way, and feed them back to glibc/kernel headers as well as integrate them into dietlibc and/or util-vserver? The kernel (resp. projects like [1] which provide sanitized headers) would be the right place for such changes. But there will pass much time before you can rely on it. These headers are/should not be provided by libc implementations. E.g. glibc.rpm from SUSE Linux 9.2 contains _syscall3() for both x86 and amd64. I'm not sure if it was in the original glibc-2.3.3 tarball or only added later by SUSE. Anyway this macro is unlikely to change and could safely be in the headers, why not? Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
On Mon, Apr 11, 2005 at 11:09:09AM +1200, Michal Ludvig wrote: Herbert Poetzl wrote: On Mon, Apr 11, 2005 at 10:29:17AM +1200, Michal Ludvig wrote: Tell me if you need something more. no, thanks I already figured it, the dietlibc needs patching as the syscall(2) for x86_64 isn't implemented .o( I wonder _what_ is running on your machine ;) I guess it was using _syscall3() instead of syscall(). Shouldn't it? yes, after I read your 'other' email ... this makes some sense ... I just wondered because I didn't know that it is available on x86_64 (headers) best, Herbert Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ 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] util-vserver + dietlibc ...
On Thu, Apr 07, 2005 at 04:40:02PM +1200, Michal Ludvig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Herbert Poetzl wrote: On Thu, Apr 07, 2005 at 04:18:45PM +1200, Michal Ludvig wrote: I'm running SuSE Linux 9.2 on AMD64 and util-linux-0.30.204 work just fine with dietlibc-0.28. Perhaps a compiler issue? My GCC says: gcc version 3.3.4 (pre 3.3.5 20040809) please could you provide an url to that dietlibc package from suse, I have several gcc's available and I'll test once the package is available ... I built the RPM myself. It's dietlibc-0.28 tarball with no additional patches. http://tmp.logix.cz/SuSE-RPMS/dietlibc-0.28/ Try to compile util-vserver without -O2 - it helped when I had problems in SL9.2 on x86 (however on amd64 it works with -O2). hmm, I had absolutely no success with the following configs: (on FC3 with util-vserver-0.30.205) - gcc 3.4.2, dietlibc-0.28 - gcc 3.4.2, dietlibc-0.28, -O0 - gcc 3.4.2, dietlibc-0.28, -Os - gcc 3.3.4 (compat), dietlibc-0.28 - gcc 3.3.4 (compat), dietlibc-0.28, -O0 - gcc 3.3.4 (compat), dietlibc-0.28, -Os - gcc 3.3.4 (compat), your dietlibc src.rpm - gcc 3.3.4 (compat), your dietlibc rpm # chcontext --xid 100 true New security context is 100 chcontext: execvp(true): Permission denied please could you provide your final rpms so that I can test if it is tools related at all? TIA, Herbert Michal Ludvig - -- * Personal homepage: http://www.logix.cz/michal -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVLmiDDolCcRbIhgRAtrNAJwLdyULc+XmEvKvEu/E6/oQ6zjpFACguMBz CfvELXsx6FyIindZjvq1GkY= =0wGH -END PGP SIGNATURE- ___ 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] util-vserver + dietlibc ...
* Enrico Scholz ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (Stephen Frost) writes: according to Enrico (please confirm or correct) the glibc has issues with the fake name resolver and is generally considered insecure because usually dynamically linked ... This really needs further explanation and justification. What about glibc being dynamically linked (and able to load other libraries) makes it insecure, specifically? 1. 'insecure', because the dynamical loading of libnss_* is uncontrollable. There is no (documented??) way to disable this loading e.g. when the chroot was entered. Executing a function which would load an nss-library does not give any guarantee that the next call to this function with another argument would not load another library. It's not uncontrollable- just don't call NSS functions after you've chroot'd. Is there some reason that's a problem? 2. the glibc NSS implementation uses caching/optimization which can cause failures in chroot operations. E.g. when the 'getpwnam()' before chroot(2) (which is used to load the libnss_* libraries) creates a connection to the 'nscd' daemon, this connection will be used for the second 'getpwnam()' (after chroot(2)) also, which will return wrong results. You will see this issue with rpm based vserver-build methods when the tools are compiled with glibc and nscd is running. I guess I'll have to look at the code but it would have been nice if you could have at least addressed the question of why it's a problem to just avoid calling NSS functions after the chroot() that I raised in my earlier reply... What changes would need to be done to make use of it secure? Provide a way to: * disable dynamic libnss_* loading * disable usage of nscd It'd be nice to be able to do this but I don't see them as being necessary to have secure tools. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Apr 07, 2005 at 12:14:48AM -0400, Paul S. Gumerman wrote: glibc seems to work fine. BTW what are the Known issues with glibc according to Enrico (please confirm or correct) the glibc has issues with the fake name resolver and is generally considered insecure because usually dynamically linked ... This really needs further explanation and justification. What about glibc being dynamically linked (and able to load other libraries) makes it insecure, specifically? What changes would need to be done to make use of it secure? It seems to me that the main thing is to just avoid the situation in the code where you've chroot'd but have yet to finish and are calling functions. Basically, make sure you don't call any functions which could load up a library (this isn't hard, esp. as I'd expect the chroot call to be basically the very last thing that's done). I'm not actually 100% sure even that situation is a problem but it's the only thing I could think of that *might* be. The specific issue Enrico is concerned with really needs to be laid out and vetted. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] util-vserver + dietlibc ...
... is not working on at least two platforms:
x86_64 (aka amd64)
---
tried several dietlibc versions
- dietlibc-0.27-4.src.rpm
- self compiled 0.28 release
- cvs release 31.Mar.2005
- debian 0.28 version
all on Fedora Core release 3 (Heidelberg)
(tools work fine with glibc, except for the known issues)
with glibc, every v* command which executes something
fails with execv*: permission denied
even disabling noexec (noexec=off) did not improve the
situation ... the following dietlibc test program works fine:
#include stdio.h
#include stdlib.h
#include unistd.h
int main(int argc, char *argv[])
{
int ret;
ret = execvp(echo, argv);
/* not supposed to get here */
if (ret)
perror(execvp);
exit(1);
}
ppc (7450)
after adding a bunch of patches to dietlibc, the
dietlibc itself compiles (0.28++) and can be installed
./configure complains ...
configure: WARNING: ext2fs/ext2_fs.h: present but cannot be compiled
configure: WARNING: ext2fs/ext2_fs.h: check for missing
prerequisite headers?
configure: WARNING: ext2fs/ext2_fs.h: see the Autoconf documentation
configure: WARNING: ext2fs/ext2_fs.h: section Present But Cannot
Be Compiled
configure: WARNING: ext2fs/ext2_fs.h: proceeding with the
preprocessor's result
configure: WARNING: ext2fs/ext2_fs.h: in the future, the compiler will
take precedence
configure: WARNING: ##
-- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##
-- ##
although the following is installed:
- libext2fs2-1.35-1mdk
- libext2fs2-devel-1.35-1mdk
and finally the compile fails with:
if diet ppc-mandrake-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -I
./lib -I ./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -O2
-fsigned-char -frename-registers -mcpu=750 -mtune=7450 -pipe -std=c99 -Wall
-pedantic -W -MT src/vshelper-sync.o -MD -MP -MF $depbase.Tpo -c -o
src/vshelper-sync.o src/vshelper-sync.c; \
then mv -f $depbase.Tpo $depbase.Po; else rm -f $depbase.Tpo;
exit 1; fi
src/vshelper-sync.c:89:4: #error vshelper relies on the Linux select()
behavior (timeout holds remaining time)
this is on Mandrake 9.1 (Bamboo) for ppc
but it fails with the very same issue on Yellow Dog Linux
(and probably Mandrake 10.1, but not tested)
please investigate!
TIA,
Herbert
PS: please let us know when you will find some time to look into it ...
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert --- a small typo here:
with glibc, every v* command which executes something
fails with execv*: permission denied
That should read:
with dietlibc, every v* command which executes something
fails with execv*: permission denied
glibc seems to work fine. BTW what are the Known issues with glibc
Herbert Poetzl wrote:
... is not working on at least two platforms:
x86_64 (aka amd64)
---
tried several dietlibc versions
- dietlibc-0.27-4.src.rpm
- self compiled 0.28 release
- cvs release 31.Mar.2005
- debian 0.28 version
all on Fedora Core release 3 (Heidelberg)
(tools work fine with glibc, except for the known issues)
with glibc, every v* command which executes something
fails with execv*: permission denied
even disabling noexec (noexec=off) did not improve the
situation ... the following dietlibc test program works fine:
#include stdio.h
#include stdlib.h
#include unistd.h
int main(int argc, char *argv[])
{
int ret;
ret = execvp(echo, argv);
/* not supposed to get here */
if (ret)
perror(execvp);
exit(1);
}
ppc (7450)
after adding a bunch of patches to dietlibc, the
dietlibc itself compiles (0.28++) and can be installed
./configure complains ...
configure: WARNING: ext2fs/ext2_fs.h: present but cannot be compiled
configure: WARNING: ext2fs/ext2_fs.h: check for missing prerequisite headers?
configure: WARNING: ext2fs/ext2_fs.h: see the Autoconf documentation
configure: WARNING: ext2fs/ext2_fs.h: section Present But Cannot Be Compiled
configure: WARNING: ext2fs/ext2_fs.h: proceeding with the preprocessor's result
configure: WARNING: ext2fs/ext2_fs.h: in the future, the compiler will take precedence
configure: WARNING: ## -- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## -- ##
although the following is installed:
- libext2fs2-1.35-1mdk
- libext2fs2-devel-1.35-1mdk
and finally the compile fails with:
if diet ppc-mandrake-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -I ./lib -I
./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -O2 -fsigned-char
-frename-registers -mcpu=750 -mtune=7450 -pipe -std=c99 -Wall -pedantic -W -MT
src/vshelper-sync.o -MD -MP -MF $depbase.Tpo -c -o src/vshelper-sync.o
src/vshelper-sync.c; \
then mv -f $depbase.Tpo $depbase.Po; else rm -f $depbase.Tpo;
exit 1; fi
src/vshelper-sync.c:89:4: #error vshelper relies on the Linux select()
behavior (timeout holds remaining time)
this is on Mandrake 9.1 (Bamboo) for ppc
but it fails with the very same issue on Yellow Dog Linux
(and probably Mandrake 10.1, but not tested)
please investigate!
TIA,
Herbert
PS: please let us know when you will find some time to look into it ...
___
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] util-vserver + dietlibc ...
On Thu, Apr 07, 2005 at 12:14:48AM -0400, Paul S. Gumerman wrote:
Herbert --- a small typo here:
with glibc, every v* command which executes something
fails with execv*: permission denied
That should read:
with dietlibc, every v* command which executes something
fails with execv*: permission denied
ah, yes, thanks for the clarification ...
glibc seems to work fine.
BTW what are the Known issues with glibc
according to Enrico (please confirm or correct)
the glibc has issues with the fake name resolver
and is generally considered insecure because usually
dynamically linked ...
best,
Herbert
Herbert Poetzl wrote:
... is not working on at least two platforms:
x86_64 (aka amd64)
---
tried several dietlibc versions
- dietlibc-0.27-4.src.rpm
- self compiled 0.28 release
- cvs release 31.Mar.2005
- debian 0.28 version
all on Fedora Core release 3 (Heidelberg)
(tools work fine with glibc, except for the known issues)
with glibc, every v* command which executes something
fails with execv*: permission denied
even disabling noexec (noexec=off) did not improve the
situation ... the following dietlibc test program works fine:
#include stdio.h
#include stdlib.h
#include unistd.h
int main(int argc, char *argv[])
{
int ret;
ret = execvp(echo, argv);
/* not supposed to get here */
if (ret)
perror(execvp);
exit(1);
}
ppc (7450)
after adding a bunch of patches to dietlibc, the
dietlibc itself compiles (0.28++) and can be installed
./configure complains ...
configure: WARNING: ext2fs/ext2_fs.h: present but cannot be compiled
configure: WARNING: ext2fs/ext2_fs.h: check for missing
prerequisite headers?
configure: WARNING: ext2fs/ext2_fs.h: see the Autoconf documentation
configure: WARNING: ext2fs/ext2_fs.h: section Present But
Cannot Be Compiled
configure: WARNING: ext2fs/ext2_fs.h: proceeding with the
preprocessor's result
configure: WARNING: ext2fs/ext2_fs.h: in the future, the compiler
will take precedence
configure: WARNING: ##
-- ##
configure: WARNING: ## Report this to
[EMAIL PROTECTED] ##
configure: WARNING: ##
-- ##
although the following is installed:
- libext2fs2-1.35-1mdk
- libext2fs2-devel-1.35-1mdk
and finally the compile fails with:
if diet ppc-mandrake-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -I
./lib -I ./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -O2
-fsigned-char -frename-registers -mcpu=750 -mtune=7450 -pipe
-std=c99 -Wall -pedantic -W -MT src/vshelper-sync.o -MD -MP -MF
$depbase.Tpo -c -o src/vshelper-sync.o src/vshelper-sync.c; \
then mv -f $depbase.Tpo $depbase.Po; else rm -f $depbase.Tpo;
exit 1; fi
src/vshelper-sync.c:89:4: #error vshelper relies on the Linux
select() behavior (timeout holds remaining time)
this is on Mandrake 9.1 (Bamboo) for ppc
but it fails with the very same issue on Yellow Dog Linux
(and probably Mandrake 10.1, but not tested)
please investigate!
TIA,
Herbert
PS: please let us know when you will find some time to look into it ...
___
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
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
Herbert Poetzl wrote: ... is not working on at least two platforms: x86_64 (aka amd64) --- tried several dietlibc versions - dietlibc-0.27-4.src.rpm - self compiled 0.28 release - cvs release 31.Mar.2005 - debian 0.28 version all on Fedora Core release 3 (Heidelberg) I'm running SuSE Linux 9.2 on AMD64 and util-linux-0.30.204 work just fine with dietlibc-0.28. Perhaps a compiler issue? My GCC says: gcc version 3.3.4 (pre 3.3.5 20040809) Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] util-vserver + dietlibc ...
On Thu, Apr 07, 2005 at 04:18:45PM +1200, Michal Ludvig wrote: Herbert Poetzl wrote: ... is not working on at least two platforms: x86_64 (aka amd64) --- tried several dietlibc versions - dietlibc-0.27-4.src.rpm - self compiled 0.28 release - cvs release 31.Mar.2005 - debian 0.28 version all on Fedora Core release 3 (Heidelberg) I'm running SuSE Linux 9.2 on AMD64 and util-linux-0.30.204 work just fine with dietlibc-0.28. Perhaps a compiler issue? My GCC says: gcc version 3.3.4 (pre 3.3.5 20040809) please could you provide an url to that dietlibc package from suse, I have several gcc's available and I'll test once the package is available ... TIA, Herbert Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal ___ 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
