On Thu, Apr 14, 2016 at 12:31:48AM +0200, Christian Boltz wrote:
> Am Mittwoch, 13. April 2016, 22:04:37 CEST schrieb Michal Kubecek:
> > 
> > I did some (very) basic testing and found only one issue: to start
> > nmbd from 4.2.4 package on a 13.1 system with AppArmor, these need to
> > be added to its profile:
> > 
> >   /var/{cache,lib}/samba/lck/ w,
> >   /var/{cache,lib}/samba/lck/* wk,
> >   /var/{cache,lib}/samba/msg/ w,
> >   /var/{cache,lib}/samba/msg/* w,
> Are those files and directories in /var/cache/samba/ or /var/lib/samba/ ?
> I'm asking because /var/lib/samba/** is covered by newer upstream 
> profiles (via abstractions/samba), while /var/cache/samba/ isn't.

Only /var/lib/samba paths were needed, I just adjusted the rules to mach
the others.

I will check if the same problem exists in SLE12 GA and openSUSE 13.2
which also upgraded from 4.1.x to 4.2.4 (and to exactly the same
package). I it does, I'll file a bug.

> > The profile is provided by apparmor-profiles package built from
> > apparmor source package. I'm not sure what would be the best way to
> > handle this:
> > 
> >   (a) add apparmor.openSUSE_13.1_Update to the project manually and
> >       submit it with the rest
> >   (b) do a separate update of apparmor and send the request to the
> > same maintenance incident once it is created
> >   (c) ignore the issue and just warn users about it
> If those changes are needed to start nmbd, option (c) doesn't sound good 
> ;-)

The directories themselves could be probably worked around by providing
them in the package (perhaps they even should be) but the rules for
lck/* and msg/* would still be needed.

However, I can't be sure these rules are sufficient. All I did was
starting nmbd and smbd and serving some files to a client. I don't
really know how to test more advanced Samba staff (like AD) as I never
needed it so there may be more. So just adding /var/lib/samba/** as
newer profiles do can be a safer choice.

> I'd even propose to do some more profile updates while we are on it.
> The 2.8 branch isn't maintained in upstream AppArmor anymore, so we
> might want to backport profile changes from the 2.9 bzr branch (which
> is the oldest maintained branch, and also what will be released as
> 2.9.3 (hopefully) soon).
> The upstream policy for profile maintenance is that usually
> permissions get added, but it's extremely rare that permissions get
> removed, which makes the risk of regressions quite low.
> However, 2.9 introduced some new rule types (like dbus and ptrace)
> which 2.8 doesn't understand, so just shipping the 2.9 profiles isn't
> possible.  (We could upgrade all of AppArmor (parser and utils) to
> 2.9.x or 2.10.x, but that's a bigger change and nothing I'd do with
> only a day or two of testing ;-)

This definitely sounds like something out of scope for Evergreen which
should IMHO have policy similar to SLE LTSS.

> I just looked at the changes between the 2.8 and 2.9 profiles and
> picked the interesting changes into the attached patch. I'm not sure
> if all changes are needed on 13.1, but IIRC at least some of them are.

I did a quick look and as far as I can see, all of them are more
permissive (except one in nscd which looks like fixing an obvious typo)
so I have no objection.

> General feedback if we want that "big" profile update patch or only a 
> "small" patch to adjust the samba/nmbd profile is also welcome.

As you seem to know that some of the changes are actually needed in 13.1
(and IIRC you mentioned one in the recent nscd thread), I would vote for
the full patch.

                                                          Michal Kubecek
Evergreen mailing list

Reply via email to