Bug#889608: man-db: man(1) dumps core (AppArmor involved)
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]
Bug#889608: man-db: man(1) dumps core (AppArmor involved)
Control: tag -1 + patch intrigeri: >> 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. There we go: https://salsa.debian.org/debian/man-db/merge_requests/1 I've verified that upgrading from 2.8.0-1 successfully unloads the profile on my system. I didn't test this upgrade path on a system that has AppArmor disabled though. Cheers, -- intrigeri
Processed: Re: Bug#889608: man-db: man(1) dumps core (AppArmor involved)
Processing control commands: > tag -1 + patch Bug #889608 [man-db] man-db: man(1) dumps core (AppArmor involved) Bug #889617 [man-db] man-db: all man pages fail to display with "command exited with status 4" Added tag(s) patch. Added tag(s) patch. -- 889608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889608 889617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#889608: man-db: man(1) dumps core (AppArmor involved)
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. Cheers, -- intrigeri
Bug#889608: man-db: man(1) dumps core (AppArmor involved)
Hi, gregor herrmann: > drop_effective_privs() > ++priv_drop_count = 1 > man: command exited with status 4: /usr/lib/man-db/zsoelim | > /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e > UTF-8 | tbl > | nroff -mandoc -rLL=146n -rLT=146n -Tutf8 > hashtable_free: 9 entries, 9 (100%) unique > (without --debug only the last line) > In parallel AppArmor says: > Feb 4 23:37:53 jadzia kernel: [1342803.492299] audit: type=1400 > audit(1517783873.721:714): apparmor="DENIED" operation="exec" info="no new > privs" > error=-1 profile="/usr/bin/man" name="/usr/bin/preconv" pid=14287 comm="man" > requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 > target="/usr/bin/man//groff" "no new privs" forbids profile transitions, see https://lists.ubuntu.com/archives/apparmor/2017-October/011142.html for details. So we have a few options: 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 B) remove the AppArmor profile entirely and rely on seccomp instead C) don't enable "no new privs" and rely on AppArmor instead Personally my choice would be A >> B >> C. Colin, if you need help with option A, please let us know :) Cheers, -- intrigeri
Bug#889608: man-db: man(1) dumps core (AppArmor involved)
On Sun, 04 Feb 2018 23:32:38 +, Colin Watson wrote: > On Sun, Feb 04, 2018 at 11:42:57PM +0100, gregor herrmann wrote: > > Since the upgrade to 2.8.0-1, man(1) is not really cooperative: > Does MAN_DISABLE_SECCOMP=1 help? Yes, `MAN_DISABLE_SECCOMP=1 man man' just works. > I may have made the mistake of only > trying this with the kernel in Ubuntu 16.04, which I suspect is relevant > here ... In case it matters, I'm not yet running the latest kernel from unstable (reboot missing) but linux-image-4.14.0-3-amd64 / 4.14.12-2 Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: The Dubliners: Spanish Lady signature.asc Description: Digital Signature
Processed: Re: Bug#889608: man-db: man(1) dumps core (AppArmor involved)
Processing control commands: > severity -1 grave Bug #889608 [man-db] man-db: man(1) dumps core (AppArmor involved) Severity set to 'grave' from 'important' -- 889608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
