On 2019-01-27 21:18, intrigeri wrote:
Control: reassign -1 bind9
Control: user pkg-apparmor-t...@lists.alioth.debian.org
Control: usertag -1 + modify-profile
Control: tag -1 + moreinfo
Thanks for your report.
I'm reassigning to the package that ships this profile, because that's
where the problem can be fixed.
Thanks! I wasn't entirely sure which package team was ultimately responsible for
this.
I'm not familiar with the BIND/Samba integration and I've never
touched the usr.sbin.named profile myself, and I'm not sure who's
upstream for it (surely the maintainers of BIND will know), so just my
2 cts:
- Regarding the 2 lines about /usr/lib/..., they are probably already
covered by these lines from /etc/apparmor.d/abstractions/base,
which usr.sbin.named includes:
/{usr/,}lib/@{multiarch}/** r,
/{usr/,}lib/@{multiarch}/lib*.so* mr,
/{usr/,}lib/@{multiarch}/**/lib*.so* mr,
It would be nice to actually test whether they're needed.
The above sample rules don't feel crazy so I say go ahead,
experiment with them and find out if which ones are needed
and if they're enough :)
Thanks for the clarification. In my /etc/apparmor.d/usr.sbin.named however the
includes for abstractions/base and abstractions/nameservice are hashed out - I
certainly didn't comment these out myself. As the top of the file currently reads:
/usr/sbin/named flags=(complain) {
#include <abstractions/base>
#include <abstractions/nameservice>
capability net_bind_service,
capability setgid,
capability setuid,
...
...
Other installations I have not in complain mode (as they've not got apparmour
installed) also have those includes commented out so I assume this is the
default setting.
- Regarding the 3 paths under /var/lib/samba/private: are they common
practice, well documented, or something you happened to come up
with locally?
If the former, and assuming they don't break a security boundary
that could be expected by users of BIND and Samba that do *not*
wish to integrate them with each other, then it would probably make
sense to add them to the profile.
If the latter, then I'm not sure what we can do except add
documentation and recommend users adapt the example rules
and add them to /etc/apparmor.d/local/usr.sbin.named.
I believe these are Debian-standard installation paths (all of the samba doc
seems to assume self-compiled install into /usr/local IIRC); all of the AD and
other information ends up living under /var/lib/samba/private by default - no
special smb.conf entries used for this. There are a number of other files in
this dir that have custom bind group permissions as well (particularly the
domain LDB files such as
/var/lib/samba/private/sam.ldb.d/DC=DOMAINDNSZONES,DC=DOMAIN,DC=NAME.ldb and
/var/lib/samba/private/sam.ldb.d/DC=FORESTDNSZONES,DC=DOMAIN,DC=NAME.ldb) but I
don't know if the permissions are shipped as-is or are a function of the domain
provision task.
As you say, for those not using bind with samba integration I'm not sure how the
config should be handled but I *think* the parts of /var/lib/samba/private
involved are all named-specific so having them enabled on a permanent basis
shouldn't represent a security risk (but again I'm not an expert).
- Regarding smb.conf, I would hope that DAC permissions would
prevent BIND from reading it if it was too crazy, right?
(I mean, BIND does not run as root, does it?)
AIUI there shouldn't be any reason bind shouldn't be able to read smb.conf as
it's world-readable by default and shouldn't contain any sensitive information,
however I'm unsure of what happens when apparmour enters the fray (I assume when
you say DAC you mean Discretionary Access Control, i.e. the apparmour rules?)
and whether this actually stops the file being read. This was merely taken from
the samba doc, I've not tested it myself yet but I didn't see any problem with it.
So all in all, if these rules work for you, I think the main
issue is about the possible security boundary violations.
Cheers,
I'll let you know when I get either the thumbs up to test or have time to
replicate on a test VM.
