FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-07-2008, 10:32 AM
Paul Howarth
 
Default End of bind-chroot-admin script

On Fri, 7 Nov 2008 13:09:05 +0100
Adam Tkac <atkac@redhat.com> wrote:

> Hi all,
>
> 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?

That's what I do anyway (I never used bind-chroot-admin). Worth a
mention in the release notes for people that do use it though.

Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-07-2008, 04:45 PM
David Woodhouse
 
Default End of bind-chroot-admin script

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?



--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-07-2008, 10:52 PM
Paul Wouters
 
Default End of bind-chroot-admin script

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 06:36 PM
"Colin Walters"
 
Default End of bind-chroot-admin script

On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul@xelerance.com> wrote:
>
> I'd rather see something replace it.

SELinux obsoletes this use of chroot for security. Every daemon
doesn't need to grow its own private copy of the OS infrastructure.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 07:47 PM
Paul Wouters
 
Default End of bind-chroot-admin script

On Sat, 8 Nov 2008, Colin Walters wrote:


On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul@xelerance.com> wrote:


I'd rather see something replace it.


SELinux obsoletes this use of chroot for security. Every daemon
doesn't need to grow its own private copy of the OS infrastructure.


You're absolutely right. And in fact, it makes a lot of things for
me a lot easier. I'll look into getting unbound proper SElinux
policies, though if anyone has pointers for me, those would be
appreciated.

Paul

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 12:43 AM
Andrew Bartlett
 
Default End of bind-chroot-admin script

On Fri, 2008-11-07 at 13:09 +0100, Adam Tkac wrote:
> Hi all,
>
> 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?

So, after this, the master configuration files will no longer live
in /etc but in /var/named/chroot/etc? Will the /etc/ files be removed?
What will prevent the frustrated admin from editing the wrong file?

As part of my efforts on Samba4, I've been trying to make it easier for
administrators to include the pre-generated zone file, and the rules for
GSS-TSIG updates (required by windows clients). I hope this will not
make it harder to have fairly generic instructions (insert this snippit
into /etc/named.conf) for my users.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 10:57 AM
yersinia
 
Default End of bind-chroot-admin script

But many people disable Selinux, so it is always better to have a secure alternatives - Selinux is better IMHO and it is possible
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@redhat.com> wrote:

On 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



I looked into unbound init script (if I understand correctly it

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@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-devel-list



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 10:58 AM
Alan Cox
 
Default End of bind-chroot-admin script

On Mon, Nov 10, 2008 at 01:34:23PM +0100, Adam Tkac wrote:
> Chroot is good and traditional method how restrict daemons. Many users
> still use it and it is far more easy create chroot configuration than
> create/maintain SELinux policy. I don't think SELinux obsoletes
> chroot, both try restrict daemon privileges and both have + and -.

chroot isn't a security feature. It helps for some non-root cases but there
are ways out of chroots and there are all sorts of fun things that can be
used to escape a chroot in the right circumstances.

Its also inadequate for some forms of attack. If I can persuade your named to
run code of my choice in a chroot without selinux then I can still use your
box as a spam machine, botnet host, DoS attack tool, proxy, etc .. all without
breaking the chroot.

In the SELinux case a lot of those actions will hit SELinux denials.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 11:26 AM
Adam Tkac
 
Default End of bind-chroot-admin script

On 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

I looked into unbound init script (if I understand correctly it
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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-10-2008, 11:34 AM
Adam Tkac
 
Default End of bind-chroot-admin script

On Sat, Nov 08, 2008 at 02:36:38PM -0500, Colin Walters wrote:
> On Fri, Nov 7, 2008 at 6:52 PM, Paul Wouters <paul@xelerance.com> wrote:
> >
> > I'd rather see something replace it.
>
> SELinux obsoletes this use of chroot for security. Every daemon
> doesn't need to grow its own private copy of the OS infrastructure.
>

Chroot is good and traditional method how restrict daemons. Many users
still use it and it is far more easy create chroot configuration than
create/maintain SELinux policy. I don't think SELinux obsoletes
chroot, both try restrict daemon privileges and both have + and -.

Adam

--
Adam Tkac, Red Hat, Inc.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 04:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org