[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: BIND less restrictive modes and policy



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 <atkac redhat com> 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

-- 
Adam Tkac, Red Hat, Inc.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]