[Libguestfs] [PATCH 3/5] sysprep: remove the custom kdump configurations

[Richard W.M. Jones]

On Thu, Oct 10, 2013 at 04:00:32PM +0800, Wanlong Gao wrote:
> On 09/09/2013 04:52 PM, Richard W.M. Jones wrote:
> > On Mon, Sep 09, 2013 at 04:09:14PM +0800, Wanlong Gao wrote:
> >> Yes, sure. Then can you give some comments about following TODO list?
> >> For which is necessary to add for users and which is not?
> >> Although we know almost all of the features we have in sysprep can be done
> >> by "--script" feature, right?
> >>
> >>
> >> "
> >> add features to remove the following files or values
> >>   if user required.
> >>
> >>   B-1) Data files which are made by iscsi initiator.
> >>        /var/lib/iscsi/*
> > 
> > Some of this is configuration apparently; ie. it is set up by
> > the iscsiadm utility.
> > 
> >>   B-2) Definition files of iscsi target emulator.
> >>        /etc/tgt/*
> > 
> > Configuration?
> > 
> >>   B-3) Definition files of iptables
> >>        /etc/sysconfig/iptables
> > 
> > Although we added this already, I'm inclined to think it is
> > configuration, not temporary data.
> > 
> >>   B-4) Definition of TCP Wrapper
> >>        /etc/hosts.*
> > 
> > Configuration.
> > 
> >>   B-5) Definition for hostname/DNS.
> >>        /etc/resolv.conf
> >>        /etc/hosts
> > 
> > /etc/resolv.conf could be removed, definitely on guests which use
> > dhcp, if there is a way to tell if a guest uses dhcp.
> > 
> > /etc/hosts seems like configuration to me.
> > 
> >>   B-6) Definition of network routing
> >>         /etc/sysconfig/network-scripts/route-*
> >>         /etc/sysconfig/network-scripts/rule-*
> > 
> > Don't really know enough to comment on this.
> > 
> >>   B-7) Temporary files
> >>         /tmp/*
> >>         /var/tmp/*
> > 
> > Yes, it was good to remove this.
> > 
> >>   B-8) kdump setting file
> >>         /etc/kdump.conf
> >>
> >>   B-9) NFS setting.
> >>       /etc/exports
> > 
> > No.
> > 
> >>   B-10) Remove all files/directories under a directory which is specified by
> >>         new virt-sysprep option
> >>  
> >>       (User may want to each directories depends on thier circumstance.)
> > 
> > Yes, good idea.  User should specify a wildcard / list of wildcards.
> > 
> >>   B-9) Remove or initialize value which is related specified users/groups.
> >>
> >>      User can select a) or b)
> >>      a) Remove specified users/groups
> >>         
> >>         - Remove definition for them from /etc/passwd and /etc/groups
> >>         - Remove their home directories.
> >>
> >>        (Don't remove the files /etc/passwd /etc/groups.)
> > 
> > Yes -- already done ('user-account').
> > 
> >>      b) Initialize normal users/groups password
> >>
> >>
> >>      Note: 
> >>            Original requirement is to remove/initaliaze 
> >>            all of normal UID/GID user's setting.
> >>
> >>            But the definition of normal user is a bit confusable.
> >>             RHEL6 : UID is 500 or more,   RHEL7 : 1000 or more
> >>            In addition, nfsnobody uses 65534.
> >>
> >>            So, specifing concrete UID/GID by command option is desirable.
> >>            For example, "--uid=500,5021000-60000"
> > 
> > Unclear.
> > 
> > ------
> > 
> > I think a better way to think about this: Suppose someone wants to use
> > virt-sysprep to get back to the original configuration of the guest at
> > installation.  Wouldn't it be better (cleaner, safer) for them to
> > install a new guest from scratch?

By the way, since I wrote all of that above, some things have changed
a bit.  virt-builder exists:

http://rwmj.wordpress.com/2013/10/05/new-tool-virt-builder/#content
http://libguestfs.org/virt-builder.1.html

and it shares some code with virt-sysprep.  And that means that
there's more potential to share "configuration" operations (like
virt-builder --hostname & --root-password) with virt-sysprep.

> According to our discussion, we thought that these configurations
> are necessary to be removed or reinitialized, that all caused by
> security reasons.
>
> For example, if we are providing user A a cloud environment GuestA,
> then we want to clone this environment to user B. We should give
> user B a clean guest, but these configurations may include some
> secure information of user A, if the administrator didn't erase
> them, user B may get some information of user A. This security
> problem is a real problem in cloud evrionments, we should find a way
> to erase or reinitialize some important configurations which may
> leak a cloud user's information to another user.
>
> Yes, "--script" can do these things by administrator, but we all
> know that it is hard, since there are many user who does not have
> expirence writing these scripts, then they may think this
> virt-sysprep tool is hard to use, throw it away.
>
> Above all, we think that we should add some features to help remove
> the configurations which may leak security informations. What do you
> think?

But going back to some of the things you mentioned, for example:

  > >>   B-8) kdump setting file
  > >>         /etc/kdump.conf
  > >>
  > >>   B-9) NFS setting.
  > >>       /etc/exports

I said "> > No."  I think I still say no.

The reason is we can't end up writing an entire configuration system
for Linux guests.

Configuration systems for Linux guests already exist: Puppet/
Chef/Ansible (and more).  It's a lot better to use those to do general
configuration.

How about this for example?

http://rwmj.wordpress.com/2013/10/05/new-tool-virt-builder/#comment-7539

That pushes the problem to well-established tools which have existed
for years that have plenty of good quality documentation.

Perhaps we could make those easier to use or more integrated with
virt-sysprep/virt-builder?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v