BIND less restrictive modes and policy

[Adam Tkac]

Hi all,

I'm going to do major revision of bind's file modes. Currenly We have
many files readable only by root and I can't see any reason why keep
binaries unreadable and unexecutable by other users. Also there isn't
any reason why keep configuration private. Only this files should not
be readable by other users:
- /etc/rndc.key - who has it may control server through rndc utility
- /var/log/named.log - will have sensitive information

All other will be readable for all. Also complete /var/named/* subtree
will be writable by named (for generating core files, DDNS updates,
secondary servers, generally for easier configuration).

Has anyone arguments against such change?

Regards, Adam

[Andrew Farris]

Adam Tkac wrote:
> Hi all,
>
> I'm going to do major revision of bind's file modes. Currenly We have
> many files readable only by root and I can't see any reason why keep
> binaries unreadable and unexecutable by other users. Also there isn't
> any reason why keep configuration private. Only this files should not
> be readable by other users:
> /etc/rndc.key - who has it may control server through rndc utility
> /var/log/named.log - will have sensitive information
>
> All other will be readable for all. Also complete /var/named/* subtree
> will be writable by named (for generating core files, DDNS updates,
> secondary servers, generally for easier configuration).
>
> Has anyone arguments against such change?
>
> Regards, Adam

Just a comment, that probably needs to accompany selinux policy adjustments (or 
rather, without change in policy other users won't have access even with mode 
changes)?

[Adam Tkac]

On Mon, Jan 21, 2008 at 04:13:14AM -0800, Andrew Farris wrote:
> Adam Tkac wrote:
> > Hi all,
> >
> > I'm going to do major revision of bind's file modes. Currenly We have
> > many files readable only by root and I can't see any reason why keep
> > binaries unreadable and unexecutable by other users. Also there isn't
> > any reason why keep configuration private. Only this files should not
> > be readable by other users:
> > /etc/rndc.key - who has it may control server through rndc utility
> > /var/log/named.log - will have sensitive information
> >
> > All other will be readable for all. Also complete /var/named/* subtree
> > will be writable by named (for generating core files, DDNS updates,
> > secondary servers, generally for easier configuration).
> >
> > Has anyone arguments against such change?
> >
> > Regards, Adam
>
> Just a comment, that probably needs to accompany selinux policy adjustments 
> (or rather, without change in policy other users won't have access even 
> with mode changes)?

Definitely. SELinux policy will be changed appropriately.

Adam

[Florian La Roche]

Hello Adam,

On Mon, Jan 21, 2008 at 12:57:38PM +0100, Adam Tkac wrote:
> Hi all,
>
> I'm going to do major revision of bind's file modes. Currenly We have
> many files readable only by root and I can't see any reason why keep
> binaries unreadable and unexecutable by other users. Also there isn't
> any reason why keep configuration private. Only this files should not
> be readable by other users:
> /etc/rndc.key - who has it may control server through rndc utility
> /var/log/named.log - will have sensitive information

ok
> All other will be readable for all. Also complete /var/named/* subtree
> will be writable by named (for generating core files, DDNS updates,
> secondary servers, generally for easier configuration).
>
> Has anyone arguments against such change?

Would it be possible to keep write access within subdirs, so that
it e.g. is possible to keep master named files owned by root.root?
(Not sure this buys anything, but still looks good...)

regards,

Florian La Roche

[Adam Tkac]

On Mon, Jan 21, 2008 at 02:19:02PM +0100, Florian La Roche wrote:
> > All other will be readable for all. Also complete /var/named/* subtree
> > will be writable by named (for generating core files, DDNS updates,
> > secondary servers, generally for easier configuration).
> >
> > Has anyone arguments against such change?
>
> Would it be possible to keep write access within subdirs, so that
> it e.g. is possible to keep master named files owned by root.root?
> (Not sure this buys anything, but still looks good...)

We should make /var/named directory writable for named (upstream has
same opinion, see
https://bugzilla.redhat.com/show_bug.cgi?id=400461#c17). So if We have
this directory writable it is not needed ship
/var/named/{data,slaves,dynamic} subdirectories because non-writable
/var/named directory is only one reason for them. Master zones
installed by default will be root:named 644 (so no write access) and
other perms will be controlled by administrator. So in the end new
schema will be:

- /etc/{named.conf,rndc.conf,rndc.key} + logfile non-readable for
  others (ok, world readable named.conf is quite suspicious so leave
  it private as is)
- /var/named will be writable and read-only permissions will be set
  per-zone by admin
- /var/named/* subdirectories will stop exist and files will be moved
  to /var/named/

Adam

[Chris Adams]

Once upon a time, Adam Tkac  said:
> /var/named will be writable and read-only permissions will be set
> per-zone by admin

If the directory is writable, read-only file permissions are
meaningless.

[Adam Tkac]

On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote:
> Once upon a time, Adam Tkac  said:
> > /var/named will be writable and read-only permissions will be set
> > per-zone by admin
>
> If the directory is writable, read-only file permissions are
> meaningless.

Maybe but what other solution will be better? I could create separate
read-only directory inside /var/named (called "masters" for example)
and put all read-only zones there but I'm not sure if admins will like
it and use it.

Adam

[Florian La Roche]

On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote:
> On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote:
> > Once upon a time, Adam Tkac  said:
> > > /var/named will be writable and read-only permissions will be set
> > > per-zone by admin
> >
> > If the directory is writable, read-only file permissions are
> > meaningless.
>
> Maybe but what other solution will be better? I could create separate
> read-only directory inside /var/named (called "masters" for example)
> and put all read-only zones there but I'm not sure if admins will like
> it and use it.

That's why the root-only /var/named with writable subdirs was very nice.
Your points about allowing core-dumps and other things like a non-complex
setup are also valid, that's why I think we should stay thinking about
this some more before reducing the security of bind.

regards,

Florian La Roche

[Chuck Anderson]

On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote:
> On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote:
> > Once upon a time, Adam Tkac  said:
> > > /var/named will be writable and read-only permissions will be set
> > > per-zone by admin
> >
> > If the directory is writable, read-only file permissions are
> > meaningless.
>
> Maybe but what other solution will be better? I could create separate
> read-only directory inside /var/named (called "masters" for example)
> and put all read-only zones there but I'm not sure if admins will like
> it and use it.

If directory layout changes are necessary, I'd rather that very 
minimal changes be made, but this seems like a good change to make to 
allow having master zone files that aren't writeable by the named 
user.

So I propose to keep the existing directory split and add the masters/ 
subdirectory if and only if it ends up being necessary to change 
permissions on /var/named/ to be writeable by the named process.

I think we should investigate whether using 'directory 
"/var/named/data";' like I mentioned in my other email works first.  
How would people feel about needing full or ../ relative paths in zone 
"file" statements?

I'll test this setup now to see if it helps with coredumps, but I 
don't think this is the root cause of the coredump failure.  I tried 
running BIND in various ways to allow coredumps to work, and even when 
running it as root with SELinux set to permissive it failed to dump 
core.  I think there are problems with the logic of the code that sets 
the Linux Capability bits.

[Adam Tkac]

On Tue, Jan 22, 2008 at 09:26:33AM -0500, Chuck Anderson wrote:
> On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote:
> > On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote:
> > > Once upon a time, Adam Tkac  said:
> > > > /var/named will be writable and read-only permissions will be set
> > > > per-zone by admin
> > >
> > > If the directory is writable, read-only file permissions are
> > > meaningless.
> >
> > Maybe but what other solution will be better? I could create separate
> > read-only directory inside /var/named (called "masters" for example)
> > and put all read-only zones there but I'm not sure if admins will like
> > it and use it.
>
> If directory layout changes are necessary, I'd rather that very 
> minimal changes be made, but this seems like a good change to make to 
> allow having master zone files that aren't writeable by the named 
> user.
>
> So I propose to keep the existing directory split and add the masters/ 
> subdirectory if and only if it ends up being necessary to change 
> permissions on /var/named/ to be writeable by the named process.
>
> I think we should investigate whether using 'directory 
> "/var/named/data";' like I mentioned in my other email works first.  
> How would people feel about needing full or ../ relative paths in zone 
> "file" statements?

This doesn't sound well for me. This will be very annoying.
> I'll test this setup now to see if it helps with coredumps, but I 
> don't think this is the root cause of the coredump failure.  I tried 
> running BIND in various ways to allow coredumps to work, and even when 
> running it as root with SELinux set to permissive it failed to dump 
> core.  I think there are problems with the logic of the code that sets 
> the Linux Capability bits.

I don't think so. As I wrote in
https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
to produce core file after setuid when /var/named directory is
writable by named user. This is main reason why I want this directory
writable. It means that you will have always core file when named
gets sigsegv (no additional setup is needed, only writable
/var/named). This change means lower security on the one hand but on
the other hand we will always get core file.

Adam

[Chuck Anderson]

On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote:
> > I think we should investigate whether using 'directory 
> > "/var/named/data";' like I mentioned in my other email works first.  
> > How would people feel about needing full or ../ relative paths in zone 
> > "file" statements?
>
> This doesn't sound well for me. This will be very annoying.

IMO, "annoying" is trumped by "more secure".  SELinux is annoying too, 
but we still use it.

I have verified that relative paths work, as well as symlinks from the 
data/ dir (not that I recommend doing it this way):

#ls -l /var/named/data
total 4
lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/

I think we need a new feature in BIND...one where the CWD can stay at 
/var/named/data regardless of the "directory" option so that zone file 
paths don't have to be changed--perhaps a new option.
> I don't think so. As I wrote in
> https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> to produce core file after setuid when /var/named directory is
> writable by named user. This is main reason why I want this directory
> writable. It means that you will have always core file when named
> gets sigsegv (no additional setup is needed, only writable
> /var/named). This change means lower security on the one hand but on
> the other hand we will always get core file.

Ok, I'll try this.  But I don't think we should change the default 
setup just to be able to generate coredumps at the expense of 
security, especially if we are still going to require SELinux to be 
put into permissive mode to make it actually work.  We should just 
document the changes one needs to make to generate coredumps since we 
already require some changes anyway, i.e.:

/etc/sysconfig/named:
DAEMON_COREFILE_LIMIT=unlimited

sysctl -w fs.suid_dumpable=1
chmod 755 /usr/sbin/named 
chmod 775 /var/named
setenforce 0
service named restart

(which of these aren't required?)

If we are going to make changes to allow coredumps by default, then 
SELinux policy should be adjusted to allow this as well because 
running your system in permissive mode for long periods of time makes 
it a royal pain to switch back--I had to boot into single user mode 
with selinux=0 and run "fixfiles restore" manually since rc.sysinit 
couldn't do it automatically (see 
https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.ht... 
for the problems I had).

I just don't think it is a good idea to implement this by making 
/var/named writeable, undoing the extra layer of security we have for 
master zone files now.  We should find some other way to mitigate 
this.  It's not like coredumps are frequent, and daemons aren't 
allowed to coredump with our default config anyway...

[Adam Tkac]

On Tue, Jan 22, 2008 at 11:30:05AM -0500, Chuck Anderson wrote:
> On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote:
> > > I think we should investigate whether using 'directory 
> > > "/var/named/data";' like I mentioned in my other email works first.  
> > > How would people feel about needing full or ../ relative paths in zone 
> > > "file" statements?
> >
> > This doesn't sound well for me. This will be very annoying.
>
> IMO, "annoying" is trumped by "more secure".  SELinux is annoying too, 
> but we still use it.
>
> I have verified that relative paths work, as well as symlinks from the 
> data/ dir (not that I recommend doing it this way):
>
> #ls -l /var/named/data
> total 4
> lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/
>
> I think we need a new feature in BIND...one where the CWD can stay at 
> /var/named/data regardless of the "directory" option so that zone file 
> paths don't have to be changed--perhaps a new option.

It is very hard to pass any new option or feature to main source.
Upstream is very very conservative. (as expected from server
developers...)
> > I don't think so. As I wrote in
> > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> > to produce core file after setuid when /var/named directory is
> > writable by named user. This is main reason why I want this directory
> > writable. It means that you will have always core file when named
> > gets sigsegv (no additional setup is needed, only writable
> > /var/named). This change means lower security on the one hand but on
> > the other hand we will always get core file.
>
> Ok, I'll try this.  But I don't think we should change the default 
> setup just to be able to generate coredumps at the expense of 
> security, especially if we are still going to require SELinux to be 
> put into permissive mode to make it actually work.  We should just 
> document the changes one needs to make to generate coredumps since we 
> already require some changes anyway, i.e.:
>
> /etc/sysconfig/named:
> DAEMON_COREFILE_LIMIT=unlimited
>
> sysctl -w fs.suid_dumpable=1
> chmod 755 /usr/sbin/named

^^^ not needed ^^^
> chmod 775 /var/named
> setenforce 0
> service named restart

^^^ should be sufficient ^^^
> If we are going to make changes to allow coredumps by default, then 
> SELinux policy should be adjusted to allow this as well because 
> running your system in permissive mode for long periods of time makes 
> it a royal pain to switch back--I had to boot into single user mode 
> with selinux=0 and run "fixfiles restore" manually since rc.sysinit 
> couldn't do it automatically (see 
> https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.ht... 
> for the problems I had).
>
> I just don't think it is a good idea to implement this by making 
> /var/named writeable, undoing the extra layer of security we have for 
> master zone files now.  We should find some other way to mitigate 
> this.  It's not like coredumps are frequent, and daemons aren't 
> allowed to coredump with our default config anyway...

Ok, so it seems that potential option to initscript which will
temporary modify /var/named perms and SELinux (for example we will
have some boolean for this) for gain such ability looks like the best
(despite I don't like it much :) )

Adam

[Steve Grubb]

On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote:
> I don't think so. As I wrote in
> https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> to produce core file after setuid when /var/named directory is
> writable by named user. This is main reason why I want this directory
> writable. It means that you will have always core file when named
> gets sigsegv (no additional setup is needed, only writable
> /var/named).

To me, that is not enough reason. You have to do some work to allow coredumps 
at all. So, the admin may as well use /proc/sys/kernel/core_name_format  to 
tell the kernel where to put the file.

-Steve

[Chuck Anderson]

On Tue, Jan 22, 2008 at 01:22:20PM -0500, Steve Grubb wrote:
> On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote:
> > I don't think so. As I wrote in
> > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> > to produce core file after setuid when /var/named directory is
> > writable by named user. This is main reason why I want this directory
> > writable. It means that you will have always core file when named
> > gets sigsegv (no additional setup is needed, only writable
> > /var/named).
>
> To me, that is not enough reason. You have to do some work to allow coredumps 
> at all. So, the admin may as well use /proc/sys/kernel/core_name_format  to 
> tell the kernel where to put the file.

Ah.  I wasn't aware that you could change the coredump path with this 
mechanism.  It sounds like that is worth investigating, but won't you 
run into the same problems with permissions on whatever directory you 
choose?  How can you choose one system-wide directory for coredumps if 
each process runs as a different user?

[Simo Sorce]

On Tue, 2008-01-22 at 13:27 -0500, Chuck Anderson wrote:
> On Tue, Jan 22, 2008 at 01:22:20PM -0500, Steve Grubb wrote:
> > On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote:
> > > I don't think so. As I wrote in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able
> > > to produce core file after setuid when /var/named directory is
> > > writable by named user. This is main reason why I want this directory
> > > writable. It means that you will have always core file when named
> > > gets sigsegv (no additional setup is needed, only writable
> > > /var/named).
> >
> > To me, that is not enough reason. You have to do some work to allow coredumps 
> > at all. So, the admin may as well use /proc/sys/kernel/core_name_format  to 
> > tell the kernel where to put the file.
>
> Ah.  I wasn't aware that you could change the coredump path with this 
> mechanism.  It sounds like that is worth investigating, but won't you 
> run into the same problems with permissions on whatever directory you 
> choose?  How can you choose one system-wide directory for coredumps if 
> each process runs as a different user?

/tmp ... <g>

Simo.

[Chuck Anderson]

On Mon, Jan 21, 2008 at 04:36:36PM +0100, Adam Tkac wrote:
> On Mon, Jan 21, 2008 at 02:19:02PM +0100, Florian La Roche wrote:
> > > All other will be readable for all. Also complete /var/named/* subtree
> > > will be writable by named (for generating core files, DDNS updates,
> > > secondary servers, generally for easier configuration).
>
> We should make /var/named directory writable for named (upstream has
> same opinion, see
> https://bugzilla.redhat.com/show_bug.cgi?id=400461#c17). So if We have
> /etc/{named.conf,rndc.conf,rndc.key} + logfile non-readable for
> others (ok, world readable named.conf is quite suspicious so leave
> it private as is)
> /var/named will be writable and read-only permissions will be set
> per-zone by admin
> /var/named/* subdirectories will stop exist and files will be moved
> to /var/named/

I think we just need to have the directory specified by "directory" in 
/etc/named.conf be writeable.  That is the CWD of the named process, 
and is where any coredumps would be written.  So perhaps instead of 
doing this overhaul of directory layout and permissions, we can just 
change the default directory to "/var/named/data" instead:

options {
        directory "/var/named/data";

This will affect zone file configurations--they will need to use 
either the full path to the zone file, or perhaps a relative path like 
"../slaves/foo.zone" which I've not tested to see if it works, e.g.:

zone "localhost" {
                type master;
                file "../localhost";
};

[Adam Tkac]

On Tue, Jan 22, 2008 at 09:19:02AM -0500, Chuck Anderson wrote:
> I think we just need to have the directory specified by "directory" in 
> /etc/named.conf be writeable.  That is the CWD of the named process, 
> and is where any coredumps would be written.  So perhaps instead of 
> doing this overhaul of directory layout and permissions, we can just 
> change the default directory to "/var/named/data" instead:
>
> options {
>         directory "/var/named/data";
>
> This will affect zone file configurations--they will need to use 
> either the full path to the zone file, or perhaps a relative path like 
> "../slaves/foo.zone" which I've not tested to see if it works, e.g.:
>
> zone "localhost" {
>                 type master;
>                 file "../localhost";
> };

It works as expected, relative paths are allowed.

Adam

[Steve Grubb]

On Monday 21 January 2008 06:57:38 Adam Tkac wrote:
> I'm going to do major revision of bind's file modes. Currenly We have
> many files readable only by root and I can't see any reason why keep
> binaries unreadable and unexecutable by other users.

What other users would be sharing a DNS server? named is traditionally used 
only on servers. It is a high value target for hackers. If they can get the 
DNS server, they can alter where all users go when they are surfing the web 
(think mega-phishing attack). If an intruder gets access to the DNS server, 
they are going after named. DNS servers are constantly under attack.
> Also there isn't any reason why keep configuration private. Only this files
> should not be readable by other users:
> /etc/rndc.key - who has it may control server through rndc utility
> /var/log/named.log - will have sensitive information

I'd keep all the configuration private. For what reason would you make a high 
value target less secure?

-Steve

[Adam Tkac]

On Mon, Jan 21, 2008 at 08:55:55AM -0500, Steve Grubb wrote:
> On Monday 21 January 2008 06:57:38 Adam Tkac wrote:
> > I'm going to do major revision of bind's file modes. Currenly We have
> > many files readable only by root and I can't see any reason why keep
> > binaries unreadable and unexecutable by other users.
>
> What other users would be sharing a DNS server? named is traditionally used 
> only on servers. It is a high value target for hackers. If they can get the 
> DNS server, they can alter where all users go when they are surfing the web 
> (think mega-phishing attack). If an intruder gets access to the DNS server, 
> they are going after named. DNS servers are constantly under attack.

Yes I know it. But I really don't know why We should keep binaries
non-readable for users. Source is open so why you need non-readable
binaries?
> > Also there isn't any reason why keep configuration private. Only this files
> > should not be readable by other users:
> > /etc/rndc.key - who has it may control server through rndc utility
> > /var/log/named.log - will have sensitive information
>
> I'd keep all the configuration private. For what reason would you make a high 
> value target less secure?

Generally on production servers only administrators have access so I
don't think this is security issue. I think it's only feeling that
configuration has to be private but I'm ready keep config files private
if you think it really makes sence. But if some flaw is found and
exploited it can't protect you.

Adam

[Chris Adams]

Once upon a time, Adam Tkac  said:
> Generally on production servers only administrators have access so I
> don't think this is security issue. I think it's only feeling that
> configuration has to be private but I'm ready keep config files private
> if you think it really makes sence. But if some flaw is found and
> exploited it can't protect you.

Many servers don't just run one service (e.g. shared web hosting servers
will run HTTP, SMTP, DNS, etc.), so the config should be protected.

Anything else might as well be world-readable though (and this is really
true for any non-config/non-log file in any RPM), since they can easily
be downloaded through "teh intertubes".

[nodata]

Am Montag, den 21.01.2008, 12:57 +0100 schrieb Adam Tkac:
> Hi all,
>
> I'm going to do major revision of bind's file modes. Currenly We have
> many files readable only by root and I can't see any reason why keep
> binaries unreadable and unexecutable by other users. Also there isn't
> any reason why keep configuration private. Only this files should not
> be readable by other users:
> /etc/rndc.key - who has it may control server through rndc utility
> /var/log/named.log - will have sensitive information
>
> All other will be readable for all. Also complete /var/named/* subtree
> will be writable by named (for generating core files, DDNS updates,
> secondary servers, generally for easier configuration).
>
> Has anyone arguments against such change?

What are the arguments for the change?

[Enrico Scholz]

Adam Tkac  writes:
> Also complete /var/named/* subtree will be writable by named

This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable.
pz/ and the other parts of the chroot filesystem must be read-only for
named.

Enrico

[Andrew Farris]

Enrico Scholz wrote:
> Adam Tkac  writes:
> > Also complete /var/named/* subtree will be writable by named
>
> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable.
> pz/ and the other parts of the chroot filesystem must be read-only for
> named.

And why exactly is that?  Any reference or reason?  What becomes exploitable if 
that is changed?

[Manuel Wolfshant]

On 01/22/2008 03:17 AM, Andrew Farris wrote:
> Enrico Scholz wrote:
> > Adam Tkac  writes:
> > > Also complete /var/named/* subtree will be writable by named
> >
> > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be 
> > writable.
> > pz/ and the other parts of the chroot filesystem must be read-only for
> > named.
>
> And why exactly is that?  Any reference or reason?  What becomes 
> exploitable if that is changed?

Bind DID have security issues in the past, providing remote root. Just 
because we have selinux and that as far as we know NOW there are no 
atack methods is not a reason to lower the difficulty bar. Just give any 
application the minimum rights needed to do what it has to do.
Any method which raises the difficulty bar for a potential attacker -- 
especially when it is already available and taking into consideration 
potential DNS poisoning attacks --  is good. Lowering the bar with no 
real gain is bad.

[Andrew Farris]

Manuel Wolfshant wrote:
> On 01/22/2008 03:17 AM, Andrew Farris wrote:
> > Enrico Scholz wrote:
> > > Adam Tkac  writes:
> > > > Also complete /var/named/* subtree will be writable by named
> > >
> > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be 
> > > writable.
> > > pz/ and the other parts of the chroot filesystem must be read-only for
> > > named.
> >
> > And why exactly is that?  Any reference or reason?  What becomes 
> > exploitable if that is changed?
>
> Bind DID have security issues in the past, providing remote root. Just 
> because we have selinux and that as far as we know NOW there are no 
> atack methods is not a reason to lower the difficulty bar. Just give any 
> application the minimum rights needed to do what it has to do.
> Any method which raises the difficulty bar for a potential attacker -- 
> especially when it is already available and taking into consideration 
> potential DNS poisoning attacks --  is good. Lowering the bar with no 
> real gain is bad.

Absolutely agreed as to the best practice ideas there, generally... but you 
didn't say it was just 'bad' you said it 'must be read-only'.  This is very 
different.  I was asking for clarification as to why it must be, not why it 
would be better not to be.  (but I think you answered that now in a way)

I'm assuming now that:
> > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be
> > > writable.

is necessary to function
> > > pz/ and the other parts of the chroot filesystem must be read-only for
> > > named.

is not necessary, only 'a good idea', a change to which you are against

[Till Maas]

On Tue January 22 2008, Andrew Farris wrote:
> Manuel Wolfshant wrote:
> > On 01/22/2008 03:17 AM, Andrew Farris wrote:
> > > Enrico Scholz wrote:
> > > > Adam Tkac  writes:
> I'm assuming now that:
> > > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be
> > > > writable.
>
> is necessary to function
> > > > pz/ and the other parts of the chroot filesystem must be read-only for
> > > > named.
>
> is not necessary, only 'a good idea', a change to which you are against

Making / read-only for bind is also not necessary for bind to work and also a 
good idea. The problem is, that it is a very rare case that something needs 
to be restricted to make something work. Therefore the best approach is to 
disallow/restrict everthing by default and only allow what is necessary to 
make it work, but not more.

Regards,
Till

[Andrew Farris]

Till Maas wrote:
> On Tue January 22 2008, Andrew Farris wrote:
> > Manuel Wolfshant wrote:
> > > On 01/22/2008 03:17 AM, Andrew Farris wrote:
> > > > Enrico Scholz wrote:
> > > > > Adam Tkac  writes:
> > I'm assuming now that:
> > > > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be
> > > > > writable.
> >
> > is necessary to function
> > > > > pz/ and the other parts of the chroot filesystem must be read-only for
> > > > > named.
> >
> > is not necessary, only 'a good idea', a change to which you are against
>
> Making / read-only for bind is also not necessary for bind to work and also a 
> good idea. The problem is, that it is a very rare case that something needs 
> to be restricted to make something work.

Which is precisely why I asked for clarification when it sounds like he was 
claiming it needed to be restricted (not likely to be needed).
> Therefore the best approach is to 
> disallow/restrict everthing by default and only allow what is necessary to 
> make it work, but not more.

No arguments here.
> Regards,
> Till

[Enrico Scholz]

Andrew Farris  writes:
> > pz/ and the other parts of the chroot filesystem must be read-only
> > for named.
>
> And why exactly is that?

To give only the required rights is a common and working practice for
years to secure daemons.  Fedora should not forget classical ways
(own uid, chroot environments, restrictive permissions) just to give
something like "easier configuration" (where I can not see how mixing
all and everything into a single dir can ease configuration).

Enrico

[Andrew Farris]

Enrico Scholz wrote:
> Andrew Farris  writes:
> > > pz/ and the other parts of the chroot filesystem must be read-only
> > > for named.
> >
> > And why exactly is that?
>
> To give only the required rights is a common and working practice for
> years to secure daemons.  Fedora should not forget classical ways
> (own uid, chroot environments, restrictive permissions) just to give
> something like "easier configuration" (where I can not see how mixing
> all and everything into a single dir can ease configuration).

I understand the idea behind minimum access restrictions; my reply/question was 
in regard to the use of the word 'must' which I assumed to be more than 
suggestion based on best practice (i.e. it won't work unless..).  Manuel 
Wolfshant said much the same that you (Enrico) did above in his reply that I 
replied to... (btw.. to Manuel, sorry I did misread and reply 'to you' when 
'you' and 'Enrico' were not one in the same, been a long day).  Anyway, that 
common practice is certainly not something that should be ignored lightly, but 
lets not confuse whether it is suggestion or necessity. (that is all I was asking)

If anyone has reason to believe real *breakage* occurs due to the change Adam 
Tkac was suggesting I hope they speak up.

[Manuel Wolfshant]

Andrew Farris wrote:
> Enrico Scholz wrote:
> > Andrew Farris  writes:
> > > > pz/ and the other parts of the chroot filesystem must be read-only
> > > > for named.
> > >
> > > And why exactly is that?
> >
> > To give only the required rights is a common and working practice for
> > years to secure daemons.  Fedora should not forget classical ways
> > (own uid, chroot environments, restrictive permissions) just to give
> > something like "easier configuration" (where I can not see how mixing
> > all and everything into a single dir can ease configuration).
>
> I understand the idea behind minimum access restrictions; my 
> reply/question was in regard to the use of the word 'must' which I 
> assumed to be more than suggestion based on best practice (i.e. it 
> won't work unless..).

No, Enrico's reply was based on best practices and common sense, not on 
"mandatory, otherwise it will break things". Adam's suggestion will just 
lower an already existing level of security.
> Anyway, that common practice is certainly not something that should be 
> ignored lightly, but lets not confuse whether it is suggestion or 
> necessity. (that is all I was asking)
>
> If anyone has reason to believe real *breakage* occurs due to the 
> change Adam Tkac was suggesting I hope they speak up.

It will not break anything but best security practices, but will bring 
no benefit either. I support 1000.00 % Enrico's view. Having a single 
directory with all zone files will not bring anything useful. OTOH (this 
is a digression, I know) it WOULD be useful if bind would include 
support for real database backends.

FWIW: Ever since 2000 I do "split DNS" by running two different daemons, 
chrooted each one it its own directory, rather then "different external 
/ internal" views. If someone is to break my external named, (s)he will 
(or should) be chroot-ed to external named's directory and hopefully 
will not be able to find out information about my internal networks.

[Adam Tkac]

On Tue, Jan 22, 2008 at 09:27:14AM +0100, Enrico Scholz wrote:
> Andrew Farris  writes:
> > > pz/ and the other parts of the chroot filesystem must be read-only
> > > for named.
> >
> > And why exactly is that?
>
> To give only the required rights is a common and working practice for
> years to secure daemons.  Fedora should not forget classical ways
> (own uid, chroot environments, restrictive permissions) just to give
> something like "easier configuration" (where I can not see how mixing
> all and everything into a single dir can ease configuration).

Main reason why I want /var/named writable is because named is
designed that this directory is supossed to be writable, not easier
configuration. It really make problems sometimes when it is not writable.
And add some option to initscript which will make that directory writable
is suspicious for me.

Adam

[Simo Sorce]

On Tue, 2008-01-22 at 01:18 +0100, Enrico Scholz wrote:
> Adam Tkac  writes:
> > Also complete /var/named/* subtree will be writable by named
>
> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable.
> pz/ and the other parts of the chroot filesystem must be read-only for
> named.

Enrico can you explain what would that prevent/change ?

Simo.