On Mon, Feb 05, 2018 at 08:20:54AM +0100, intrigeri wrote:
> intrigeri:
> > A) drop the child profiles (groff, filter), merge their rules into the
> >    main /usr/bin/man profile, and use ix instead of Cx; these rules
> >    are not particularly scary so this doesn't seem crazy an option
> 
> I had a closer look and what's scary is not the rules that can be
> found in the child profiles, it's the fact that if we drop the child
> profiles, all processes run by man will have full access to the
> filesystem:
> 
>   # The purpose of this profile isn't to confine man itself (that might be
>   # nice in the future, but is tricky since it's quite configurable), but to
>   # confine the processes it calls that parse untrusted data.
>   /** mrixwlk,
> 
> … i.e. the /usr/bin/man profile would be mostly useless. So let's
> forget about option A and instead choose between:
> 
> > B) remove the AppArmor profile entirely and rely on seccomp instead
> > C) don't enable "no new privs" and rely on AppArmor instead
> 
> I think B is fine given all the non-AppArmor hardening efforts Colin
> has been putting into man-db recently.

I posted to intregeri's merge request about this, but just to have it in
the BTS:

  Thanks - I'm sure this would work, but I don't want to take this
  approach.  My intent was to use both seccomp and AppArmor for the
  groff-related subprocesses (which seems to work fine with older
  kernels, though maybe my testing is inadequate): seccomp serves to
  confine most of the space of possible system calls they might make,
  while AppArmor restricts the parts of the filesystem they can use
  (which seccomp can't do).

  I'm hoping that it's still possible to use both, but I clearly need to
  do more testing on recent Debian kernels.  However, for now, a much
  less invasive workaround is to disable the seccomp filtering, which
  doesn't require complicated maintainer script code.  I'll go ahead and
  do that.

The two things I intend to try are:

  1) stack the child profile on the parent one, so that the kernel knows
     it's a reduction in privilege (I can't get the syntax for this to
     work, but am asking around with AppArmor experts at work)
  2) failing that, link man with libapparmor and do the profile
     transitions manually with aa_change_profile before putting the
     seccomp filter in place (I'd prefer to avoid this, but it's an
     option)

-- 
Colin Watson                                       [cjwat...@debian.org]

Reply via email to