From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Fri 01 Mar 2002 - 19:49:37 GMT
On Wed, 27 Feb 2002 22:41:07 -0500, Klavs Klavsen wrote
> > > However it seems a little off.. my skel server, which has a bare minimum
> > > of spaceusage, it says uses 325000K and that sounds like it's not
> > > unified at all :-(
> > vdu simply counts the space used by all file with a single link. It assumes that
> > any file with more than one link is probably unified, which is almost true
> > (very few files in a linux distribution are hard linked together)
> which would mean, that my skel-server is not unified against the base system?
> 325mb is a lot for config files only, However a du -csh /vserver/skel
> says 403mb - which means that there are some unified files. Can this
> have anything to do, with the fact that I've rpm -e a lot of packages
> within the skel server? (didn't use vrpm).
vrpm is need to apply the same rpm commands to multiple vserver. It is just
a helper. No magic
If you remove some rpms from the reference server, then there is no way
another vserver may be unified on it. The unification work with packages.
it finds common package (same version) and then find out which files are
not config file and then unified them. So if the base server has less package
than a vserver, they can't be unified.
> > > > 2) get a list of files, that is not unified (or a list of files that
> > > > are?) - this way I could easily check for changes in a vserver - such as
> > > > evidence of hackers and such.
> > vdu could use this instead. If the file has the immutable bit on, and has
> > more than one link, it must be unified.
> the immutable-unlink flag, could be checked with lsattr (if so, what's the letter
> for it?)?
> > I am thinking about a new utility called vfiles. This utility will produced
> > a list of file not unified by comparing a vserver with either a reference
> > vserver or a package list (a package list + versions in a text file).
> sounds interesting, and definetely useful. Would be a good thing to make
> some switches, just like DU so one can choose how and what the user
> exactly wants. As I see, it there are a few uses for different kind of
> output, which basically belongs to the unified / not-unified
> question.(f.ex. the ability to find files, that are outside, the
> "not-unified" dirs only, and have been un-unified etc.).I'm sure you can
> think of many more.
> > Tonight I wanted to bring a vserver home (how cool :-) ). So I tar it and compress
> > it. Got 500megs. Not so bad. It fits on my notebook. But wait, 90% of the files
> > in there are already available on my workstation at home. No need to bring them.
> But are they the exact version? would require, that you the same version
> of RH, and have applied the same updates.
Yes. vfiles will be able to compute either by comparing a reference vserver
or by comparing a text file with package/version. This file would contain the
list of all package in a distribution. All original package in fact. Using this, you would
be sure that you can unify the vserver at home, because the tarball will contain
all the extra packages.
> > Using vfiles, it becomes very easy to backup a vserver in the root server
> > and then compare that to prove the vserver has not been hacked.
> One of the very interesting features. However, it should be possible to check this
> comparing against a backup - f.ex. by having a list of files that
> "should be" unified - and then checking if they still are. If they have
> been unlinked - something weird is up.. and if you know you updated the
> vserver only, then you could just update the list of unified-files.
> The list of should-be unified files, are also good to apply a
> tripwire-like checksum check root against vserver, if one does not have
> a checksum database installed.
> > But I would like to see something else in this area. For example, a per
> > vserver flag could change the meaning immutable-unlink fiag. It would
> > be possible to turn the vserver flag on and off from the root server. When
> > the per server flag (called it "frozen") is turned on, the ummutable-unlink
> > flag is disregarded. This means, instantly, all unified files turned to immutable
> > only: A vserver is not allowed to changed them anymore.
> is this not possible now, by removing the immutable-unlink flag, from
> the necessary vservers only? sorry if I'm a but dumb here, but what's
> the extra features with the per vserver flag?
No. The immutable flag is stored in the inode. So if you remove the flag, all
vserver are loosing the immutable flag. Further, it is a long process. you have
to walk the vserver and touch every file.
Having a way to turn a global attribute on and off on one vserver only seems the
way to go.
> > All those funny feature could be implement using the Linux Security Module
> > I think.
> I would love to hear what your plans are with the LSM and vserver. I visited Openwall
> but couldn't find any texts about what LSM is, and what it enables.
Ideally, the vserver project should be done on top of LSM. LSM (linux security module)
is really a framework where anyone will be able to introduce all kind of
weirdness (I mean creativity) to enhance security or even make the system
more usable. So instead of having everyone hacking in the kernel and ending
with a kernel looking like
if (joe's feature is on) return some_error
if (jack's feature is on) return some error
all those idea will be done as LSM pluggin. The core kernel would only talk
to the LSM.
Some ideas of the vserver are readily doable with the LSM. Some can't be
implemented. Since both LSM and vserver are kind of evolving, it is too soon
to try to tie both project. The major problem with vserver is that it is not
only introducing new access rules, but also virtualisation. LSM is currently
more about introducing new access rules and less about changing the behavior
of a system call.
It seems like most security enhancement project are moving to LSM these days.
This is cool because it will allow more people to try those system. Because of the
modular nature, it should be possible to try the NSA secure offering on
your box without even rebooting :-)
> > Using kernel ctx-8, samba should work fine in a vserver. The only issue is
> > that the vserver must be either in the DNS or you must use a WINS to reach
> > it (which you probably do anyway).
> Great. what change enabled this? (i'm curious by nature :-)
vserver can use their ipv4root (their assigned IP) or 127.0.0.1. The kernel
remap 127.0.0.1 to the ipv4root in connect and bind system call.
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!