[Samba] Debian Buster, bind_dlz, and apparmor

Tue Nov 28 18:09:59 UTC 2017

On 11/28/2017 11:56 AM, Rowland Penny via samba wrote:
> On Tue, 28 Nov 2017 11:24:58 -0600
> Dale Schroeder <dale at BriannasSaladDressing.com> wrote:
>
>> On 11/28/2017 11:11 AM, Robert Wooden wrote:
>>> Dale,
>>>
>>> Been using Ubuntu server for years in my AD. Discovered a long time
>>> ago that apparmor is not needed for a server. (Someone is probably
>>> going to argue the other that is should be but . . .)
>>>
>>> Do not quote me but, I have read that AppArmor is intended more for
>>> a desktop environment. I have always disabled and then removed
>>> AppArmor and have never had any issues. Of course I am behind a
>>> hardware firewall so, hopefully, no exposure to any unwanted
>>> attacks.
>>>
>>> All my servers work fine without AppArmor.
>>>
>>> As an Ubuntu user, my 2 cents . . .
>>>
>>> On Tue, Nov 28, 2017 at 10:55 AM, Dale Schroeder via samba
>>> <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote:
>>>
>>>      On 11/28/2017 9:02 AM, Rowland Penny wrote:
>>>
>>>          On Tue, 28 Nov 2017 08:37:22 -0600
>>>          Dale Schroeder via samba <samba at lists.samba.org
>>>          <mailto:samba at lists.samba.org>> wrote:
>>>
>>>
>>>              On 11/28/2017 2:38 AM, Rowland Penny via samba wrote:
>>>
>>>                  On Mon, 27 Nov 2017 14:53:32 -0600
>>>                  Dale Schroeder via samba <samba at lists.samba.org
>>>                  <mailto:samba at lists.samba.org>> wrote:
>>>
>>>                      Last week, Debian testing (Buster) added
>>> apparmor to the list of
>>>                      dependencies for its latest kernel release,
>>>                      apparently because
>>>                      systemd needs it.  Recently, I noticed my first
>>>                      casualty - bind9 -
>>>                      due to apparmor failures with bind_dlz.
>>>
>>>                      Knowing next to nothing about apparmor, what is
>>>                      needed to fix this,
>>>                      and what further info do you need from me?
>>>
>>>                      Thanks,
>>>                      Dale
>>>
>>>                  I cannot seem to find a debian kernel that has a
>>>                  dependency on
>>>                  apparmor, can you provide a link ?
>>>
>>>                  Even if debian is making the kernel depend on
>>> apparmor (by the way,
>>>                  does Linus know about this  ?), this isn't a Samba
>>>                  problem, it is an
>>>                  apparmor one.
>>>
>>>                  Rowland
>>>
>>>              Rowland,
>>>
>>>              Thanks for responding.
>>>
>>>              From
>>>              http://metadata.ftp-master.debian.org/changelogs/main/l/linux/linux_4.13.13-1_changelog
>>>              <http://metadata.ftp-master.debian.org/changelogs/main/l/linux/linux_4.13.13-1_changelog>
>>>
>>>              [ Ben Hutchings ]
>>>                  * linux-image: Recommend apparmor, as systemd units
>>>              with an
>>>              AppArmor profile will fail without it (Closes: #880441)
>>>
>>>              So, although the word "recommend" implies that one has a
>>>              choice, in
>>>              reality, the kernel upgrade would not proceed without
>>>              installing
>>>              apparmor.
>>>
>>>          Then it is a bug, depend means it will be installed,
>>> recommend means
>>>          what it says, it is recommended to install it, but you do
>>> not need to.
>>>
>>>              I suppose it would be possible to disable, but assuming
>>>              the systemd
>>>              warning is a harbinger of things to come, it seemed best
>>>              to me to
>>>              figure it out now.  I know systemd is not your thing,
>>> and I am inclined to agree; however, Debian sees it otherwise,
>>>              leaving me to
>>>              deal with it.
>>>
>>>          Easier way out of this, stop using debian and use Devuan
>>> instead.
>>>
>>>              I asked here because there is a wiki section devoted to
>>>              the topic -
>>>              https://wiki.samba.org/index.php/BIND9_DLZ_AppArmor_and_SELinux_Integration
>>>              <https://wiki.samba.org/index.php/BIND9_DLZ_AppArmor_and_SELinux_Integration>
>>>
>>>              Thus far, SELinux has not been forced by Debian.
>>>              Regardless, since
>>>              the apparmor install, I have not been able to get Bind9
>>> to start if
>>>              bind_dlz is enabled.
>>>
>>>          As I said, apparmor has nothing to do with Samba, the same
>>>          goes for
>>>          selinux and, in my opinion, they should figure out how to
>>> work with
>>>          Samba, not the other way round. The page on the wiki is
>>>          supplied as a
>>>          service, but Samba has no real way to know if the settings
>>> are correct,
>>>          it relies on feedback from users.
>>>
>>>          Rowland
>>>
>>>      Likewise, I had hoped some of the Ubuntu or Red Hat-derived OS
>>>      users would chime in.  I had previously tried several different
>>>      incantations with no luck.  Just now, I found this, taken from
>>>      https://2stech.ca/index.php/linux/linuxtutotials/tutorials/234-samba-active-directory-with-bind-dns-backend-on-ubuntu-1404
>>>      <https://2stech.ca/index.php/linux/linuxtutotials/tutorials/234-samba-active-directory-with-bind-dns-backend-on-ubuntu-1404>
>>>
>>>        /var/lib/samba/private/krb5.co <http://krb5.co>nf r,
>>>        /var/lib/samba/private/dns.keytab r,
>>>        /var/lib/samba/private/named.conf r,
>>>        /var/lib/samba/private/dns/** rwk,
>>>        /usr/lib/x86_64-linux-gnu/samba/** m,
>>>        /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/** m,
>>>
>>>      This dated recipe works for me where newer ones did not. BIND
>>>      9.10.6 is happy again.  YMMV
>>>
>>>      Dale
>>>
>>>      --
>>>      To unsubscribe from this list go to the following URL and read
>>> the instructions: https://lists.samba.org/mailman/options/samba
>>>      <https://lists.samba.org/mailman/options/samba>
>>>
>>>
>>>
>>>
>>> -- 
>>> Thank you. Bob Wooden
>>>
>>> 615.885.2846www.donelsontrophy.com <http://www.donelsontrophy.com>
>>>
>>> "Everyone deserves an award!!"
>> Bob,
>>
>> I agree with everything you say and would rather not have it, but if
>> Debian's kernel maintainers are correct in that more systemd service
>> files will require apparmor, what other choice do I have but to learn
>> it?  I am not sure why Debian has decided to follow the
>> systemd/apparmor path, but I guess I get to go along for the ride. If
>> it becomes too onerous, I may have to do as you did and remove it.
>> BTW, the apparmor file for ntp worked out of the box, no
>> modifications on my part required.
>>
>> Thanks,
>> Dale
> The problem is that debian has fixed only half of the problem, yes
> recommend apparmor by all means, but they also need to fix systemd
> units to NOT fail if apparmor isn't installed, after all, apparmor is a
> 'recommend' and not a 'dependency'. If some systemd units fail if
> apparmor isn't installed, then this is, undoubtedly, a bug.
>
> Mind you, all of this is irrelevant to me, I do not use systemd ;-)
>   
> Rowland
>   
>
You're a lucky guy, Roland. ;-) I've been burned several different times 
with different aspects of systemd, even prior to apparmor.

You are absolutely correct in that the released systemd units should all 
work from the beginning.  I hope that it gets more reliable; time will tell.

Dale