Currently, there is no Linux distribution (no OS in fact) which may answer those questions. Once a server has been abused, the intruder may have changed quite a lot and may have cover his tracks. When you execute a command on such a machine, you can't really trust the output.
Now, on a linux server running vservers and no network service in the root server, you have one part of the solution. The root server and the kernel can't be tempered. So you can always trust the various commands you are running.
Now proving that along its entire life, the root server has never been opened to crack attempt, is a difficult project. All I say is that a root vserver can't be modified from the vservers or anywhere else if it has no network service.
This is nevertheless one goal of the vserver project. Create a robust and trusted root server in which you can run all kind of more flexible virtual servers.
Back to our normal schedule...
So if you trust the root server and you trust another (reference) vserver (one which is never running), you can use the vcheck utility to perform an rpm verify command, but using the RPM database in the reference vserver. The corresponding packages will be checked.
vcheck --verify refvserver vserver1 vserver2 ...
vcheck has another option, --diffpkgs, to compare the package list in to vserver. You can see how to vservers evolved.
/usr/sbin/vserver server exec command "argument with space"
And the command will receive a single argument.
The other section is called NIS/Ldap. It lets you enter the NIS domain, NIS server, LDAP base dn and LDAP server.
Both section are normally found at the end of the installation of a Linux distribution.
This information is enabled in the vserver using the authconfig command. Not all distribution carry this command. We will have to figure out how to enable this on all distribution. If /usr/sbin/authconfig is missing in the vserver, the information is not applied. So newvserver works anyway.
/usr/lib/vserver/install-rh8.0 redhat full
Now, if you run this with the Redhat supplied kernel (2.4.18-14), it works. If you use a 2.4.19 kernel (2.4.19ctx-14 for example), rpm installs few package and then wait forever, trapped in a pause() system call.
I have not yet explain this behavior.
The --nodev option tells vserver not to skip this step.
/usr/sbin/vserver --nodev server enter
An IP alias will be set on this virtual device after configuring it. It uses the loopback number as the default IP to configure the vlan device.
to perform the getpwnam() call, glibc uses NSS (Name Service Switch) plug-gins to access the user information. These plug-gins are taken in the vserver environment and are not always compatible with the root server glibc.
To avoid this problem, we really need two utilities. One running in the root server, switching root and then calling another (/bin/id ?) in the vserver to learn about the user. This way, both utilities will be compatible with each world. Remember that a root server may be some Linux distribution/release and the vserver may be running a totally different distribution/release.
For now, I have fixed the problem somewhat, but it is not perfect Before switching root, I perform a getpwnam("root"), so the plug-gins are loaded. When I perform the real getpwnam, after the switch, the plug-gins are already in memory so they work. Further, if the target user is root, I do not need to perform any of this and uses the UID 0.
Note that this capchroot feature is needed by the suexec sub-command of the vserver command.
This cheat kind of works. It works for most people. Now, if your vserver is running NIS and not your root server, for example, then the NSS plug-gins loaded are not the one needed in the vserver. In this case it does not work.
We will need a better solution. For now, what we have will work for pretty much everybody.