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-10-2008, 11:36 AM
Adam Tkac
 
Default End of bind-chroot-admin script

On Mon, Nov 10, 2008 at 12:43:00PM +1100, Andrew Bartlett wrote:
> 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?

Master configuration will be in /etc and /var/named by default like
now. Only one difference is when you want to use chroot you have to move
configuration files to chroot manually.

>
> 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

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:47 AM
Enrico Scholz
 
Default End of bind-chroot-admin script

Alan Cox <alan@redhat.com> writes:

> 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.

Can be prevented with traditional tools too:

iptables -A OUTPUT -m owner --uid-owner named -j o-NAMED




Enrico

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

Well, it is off topic IMHO with the principal mail subject but the discussion is so interesting so some consideration on the point could be useful

http://etbe.coker.com.au/2007/08/22/se-linux-vs-chroot/


of Russel Cooker



On Mon, Nov 10, 2008 at 2:26 PM, Adam Tkac <atkac@redhat.com> wrote:

On Mon, Nov 10, 2008 at 06:58:38AM -0500, Alan Cox wrote:

> 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.



Well, we are quite OT but could you point me how daemon could escape chroot

when it is written correctly?



>

> 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.

>



Right you are but when you are using chroot it is very hard to do

such attack. I think it is nearly impossible insert and run such long

arbitrary code especially when binary is compiled with stack protector.



Make sure I also think SELinux is better but it doesn't mean that

chroot is useless and obsoleted.



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, 11:59 AM
Matthew Garrett
 
Default End of bind-chroot-admin script

On Mon, Nov 10, 2008 at 02:26:30PM +0100, Adam Tkac wrote:

> Well, we are quite OT but could you point me how daemon could escape chroot
> when it is written correctly?

If the daemon is written correctly then you wouldn't need the chroot in
the first place. The fundamental assumption behind these security
policies is that you don't trust the software.

--
Matthew Garrett | mjg59@srcf.ucam.org

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

On Mon, Nov 10, 2008 at 06:58:38AM -0500, Alan Cox wrote:
> 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.

Well, we are quite OT but could you point me how daemon could escape chroot
when it is written correctly?

>
> 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.
>

Right you are but when you are using chroot it is very hard to do
such attack. I think it is nearly impossible insert and run such long
arbitrary code especially when binary is compiled with stack protector.

Make sure I also think SELinux is better but it doesn't mean that
chroot is useless and obsoleted.

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, 04:03 PM
Paul Wouters
 
Default End of bind-chroot-admin script

On Mon, 10 Nov 2008, yersinia wrote:

> 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
> )

The question is, is it worth the hassle of maintaining the chroot. This is
important for both named and unbound as they will be able in the near
future to include dnssec keys, which will be provided by a different
package. So one has to update the chroot when a "third party" package
updates itself.

I'm currently doing this with the unbound nameserver, but it is quite
ugly.

Paul

--
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 10:05 PM.

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