to do "chroot" better with selinux (http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html)
On Mon, Nov 10, 2008 at 1:26 PM, Adam Tkac <atkac@xxxxxxxxxx> wrote:
I looked into unbound init script (if I understand correctly itOn Fri, Nov 07, 2008 at 06:52:10PM -0500, Paul Wouters wrote:
> On Fri, 7 Nov 2008, David Woodhouse wrote:
>
>> On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
>>> bind-chroot-admin script should sync BIND configuration files to
>>> chroot() directory. It was written with good intention but it has
>>> never worked correctly in all situations. There is long history with
>>> many broken configurations and urgent severity bugs.
>>>
>>> I'm going to remove this script from Fedora 11 (it is part of Fedora/RHEL
>>> only, no other distro uses it). After removal, "standard" chroot
>>> structure will be created when you install bind-chroot package. It
>>> will contain all needed files for running named in chroot but admin
>>> shall move needed configuration files to chroot manually. Do you have
>>> any comments?
>
> I'd rather see something replace it. For unbound, another caching resolver
> with chroot (which got pushed in the repository a few days ago), the
> same problem is solved by copying/linking/mounting files in the
> chroot via the init script.
>
> Updating the chroot becomes important for shipping DNSSEC keys via a package.
> I am putting in a review request today for a new package 'dnssec-keys'
> that allows people to easily enable/disable DNSSEC and preload the proper
> keys for active TLD's. Things should get easier once the root is signed.
>
> I was about to look at bind, since the DNSSEC key format for unbound and
> bind is the same, so I am using one include file that will work on both
> nameservers, once they copy it into their chroot environment.
>
> Have a look at the unbound method, and see if that is something that could
> also work for named?
>
> Paul
deals with chroot symlinks). Unbound uses only small amount of
configuration files so it is quite easy to create chroot.
If you look into bind-chroot-admin it tries deal with all possible
situations and it sometimes doesn't work and when something fails
it generally breaks configuration which is, of course, pretty bad.
BIND has good SELinux policy so for "mainstream" configurations chroot
is simply not needed.
Chroot is used by traditional admins whose create it manually or when
you need really secure environment (chroot+SELinux). Both cases
doesn't need bind-chroot-admin because in the first case user doesn't use
it and in the second case configuration is maintained in some kind of
VSC (CVS, SVN etc...) and bind-chroot-admin makes only problems.
Adam
--
Adam Tkac, Red Hat, Inc.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
