[Pkg-samba-maint] Bug#896080: [samba] Improve AppArmor integration

[Mathieu Parent]

Package:samba
Version: 2:4.7.4+dfsg-2

Ensuring we won't forget this feature request.

Mathieu Parent


---------- Forwarded message ----------
From: Christian Boltz <apparmor at cboltz.de>
Date: 2018-03-20 23:50 GMT+01:00
Subject: Re: [apparmor] Let's enable AppArmor by default (why not?)
To: apparmor at lists.ubuntu.com
Cc : Seth Arnold <seth.arnold at canonical.com>, Marvin Renich
<mrvn at renich.org>, Debian Samba Maintainers
<pkg-samba-maint at lists.alioth.debian.org>,
debian-devel at lists.debian.org


Hello,

Am Dienstag, 20. März 2018, 01:37:03 CET schrieb Seth Arnold:
> On Mon, Mar 19, 2018 at 10:10:02AM -0400, Marvin Renich wrote:
> > Is there a way that an app (e.g. smbd) whose file access
> > requirements
> > change dynamically through admin and user configuration can at least
> > inspect its own apparmor profile and give the user a clue that the
> > admin must update the profile?
>
> Our friends at SUSE have a script that automatically generates
> portions of an AppArmor profile for Samba based on the Samba
> configuration: https://bugzilla.novell.com/show_bug.cgi?id=688040
>
> I'm not entirely sold on the idea, as a hand-authored security policy
> can serve as belt-and-suspenders against misconfiguration or a broken
> management system that allows unauthenticated users to create too-wide
> shares.
>
> The usability gain is undeniable.

As the author of that script, I can tell you that it made *lots of*
users happy ;-)  Before we had that script, we[1] got a bugreport each month
about AppArmor denials in Samba because of shares outside of /home.
Since the script is in use, that number went down to zero :-)

Yes, there is a risk that a samba misconfiguration results in too wide
permissions, but the script has a few safety checks and won't auto-add
- paths with variables (anything containing a % sign)
- "/" - because sharing your complete filesystem is insane
to reduce that risk.

The big advantage of the script is that we can ship the samba profile
in enforce mode without annoying users ;-) - and that's much better
than having to disable the profile by default because it breaks Samba
with non-default configuration/shares.
Oh, and the smb profile helped to prevent exploiting SambaCry :-)

I'll attach the latest version of the script to this mail. [2]

You'll need to call it in smb.service as:
    ExecStartPre=/usr/share/samba/update-apparmor-samba-profile

You'll also need to apply
    https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1
to the smb AppArmor profile to include the autogenerated sniplet. [3]


Regards,

Christian Boltz

[1] Just in case it isn't obvious on Debian mailinglists - "we" means
    "openSUSE" ;-)

[2] directly taken from the package:
        https://build.opensuse.org/package/show/openSUSE:Factory/samba
    (it's in the vendor-files-*.tar.bz2 tarball)

[3] Actually it should now be possible to push this patch upstream
    using "#include if exists" ;-)

--
I am supposed to be the info provider, so here is my answer:
42
By the way:
What is the question?
[Johannes Meixner in https://bugzilla.novell.com/show_bug.cgi?id=190173]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update-apparmor-samba-profile
Type: application/x-shellscript
Size: 2667 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-samba-maint/attachments/20180419/be09a6f5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-samba-maint/attachments/20180419/be09a6f5/attachment-0001.sig>