From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Thu 10 Jan 2002 - 02:45:57 GMT
On Mon, 7 Jan 2002 22:28:40 -0500, Gil Vidals wrote
> Hi,
>
> I think James' idea of using vunify to combine the common files
> through hardlinks is excellent. In the end, this will probably
> be the route I take.
>
> However, I have a completely different approach for hosting 250
> VServers, and I would appreciate comments and thoughts on this
> before I move forward.
>
> Instead of creating a unique VServer per user, what if I had one
> large VServer that hosted 250 users. The large VServer will
> protect the base system from any malicious users or run away
> processes. The drawback is that the various users could wreak
> havoc on each other.
Having a single vserver on a machine is probably a better idea than
just having the root server doing all the tasks. One major advantage is security
-A vserver is less powerful than a root server. There are many things it is not
allowed to do:
reconfigure the network
run a packet sniffer
send raw packets (forged packets)
The root server can be used to monitor and track intrusion in the vserver. Basically
with some packaging, the vserver project will allow someone to answer the following
question:
Has this server been cracked
Currently, on all OS, the only answer is either
Yes it has been cracked
or
I don't think so
The answer "no" is not possible because once a server is cracked, the intruder
may have changed various things here and there and cover its track. You can
trust the system to audit itself. Sure, most intruder these days seems quite happy
to tell you they did the exploit and general sabotage the system to make sure you
will find out. But an intruder can change so many things on the system that
you may have no trustable tool to audit the system.
The root server, running no network service, is almost impossible to cracked (kernel
bug pending). So it can be used to run various task such as tripwire and friends
to detect intrusion. Further, once a server is reliable, it can be locked (immutable)
making it unchangeable by an intruder.
This goes on and on.
But the vserver idea does not force a split in many vservers. It is often pratical
to have severai vserver to isolate tasks. For example, one may install a vserver
for email, a vserver for web and a vserver for sql. The idea is that a cracked
one won't be able to affect the other. Also, this is often easier to perform updates
on a server you know does little tasks.
> In this scenario how do I control /bin/bash? I guess I don't
> understand when the /usr/sbin/chcontext /bin/sh command will
> execute. Users will telnet or ssh in and I don't understand at
> which point the chcontext command is called or exactly who calls
> it??? Someone please help me understand.
The chcontext stuff is executed once when the vserver is started. The side
effect of chcontext, chbind and friends is to installs some settings in a process.
Then all processes started by this process inherit those settings.
When you do
/usr/sbin/vserver xx start
it creates one process with the proper security context and the proper
IP binding and then let this process starts the various services in the vserver.
For example, after running vserver xx start, there is probably an sshd left running.
This sshd is trapped in the vserver root (/vservers/xx) and the vserver security
context and IP binding. So when a user log to ssh, the shell started inherit
all those settings so is trapped as well. From this sshd, this is /bin/bash which
is started, but from the root server perspective, this is /vservers/xx/bin/bash.
And this is true for all service. Said completly differently, if you do an ssh
to the root server, then sshd will execute some code until /bin/bash is started.
If you do an ssh to one vserver, then its sshd will perform the exact same operation
with the same performance and will fire its /bin/bash. There is no chcontext
utility involved. No special monitor,translator,whatever.
Hope this helps!
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc